Ага, Ден потім вибачився, що обмовився і деяких людей трохи неправильно називав :)

Поетрі не вміє безсекретної публікації 🤷‍♂️

Власне, ми з українськими опенсорцерами це останнім часом намагалися донести типу отак twitter.com/...​tatus/1626505020630872064. Та от вестернери усеодно $100k персонажу накидали.

Власне, ми з українськими опенсорцерами це теж обговорювали. Ось, навчальні треди для вестернерів є типу twitter.com/...​tatus/1626505020630872064. Та й наколупали більше подібних висловлювань. Десь ажіотаж збили, але йому всеодно понад $100k накидали.

Хоча б у можливості штук типу eiara.nz/...​ncident-on-the-fediverse

Гуглити Fediverse. Взагалі, це місця, куди переїхали купа технічних твіттерських з приходом маска.

Можна створити ще один англійською, а потім їх об’єднати кнопочкою ось на цій сторінці www.linkedin.com/...​ferences/d/merge-accounts.

Можна створити ще один англійською, а потім їх об’єднати кнопочкою ось на цій сторінці www.linkedin.com/...​ferences/d/merge-accounts.

Можна створити ще один англійською, а потім їх об’єднати кнопочкою ось на цій сторінці www.linkedin.com/...​ferences/d/merge-accounts.

Запускати тести через pre-commit однозначно крінжово. Всі обгортають в tox чи щось подібне, бо тестування ж може відбуватися в багатьох енвах, і треба ціла матриця.
Додавати в локальний ґіт реп дуже сумнівна ідея. Крім того, зараз є ґітхаб-апка, яка запускається в пул-реквестах і навіть зміни комітить назад: pre-commit.ci.

Ладно, не останнє. Глянув на setup.py і жахнувся:
— tests_require — давно депрекейтнуто, не варто показувати таке людям
— setup.py не використовує жодної фічі, яка можлива тільки з ним, його можна *повністю* переписати як setup.cfg (так, навіть включення контенту з рідмі; ба більше — я колись контрибютив фічу збирання long_description із кількох файлів, типу long_description = file: README.md, CHANGELOG.md)
— в сучасному світі слід декларувати інтерфейси PEP 517, там мінімальна версія setuptools (якщо юзається) і т.д. Жодних ручних низькорівневих маніпуляцій з setuptools/wheel не потрібно. Для цього є build (чи той же поетрі).
— мішанина poetry і setuptools — це взагалі якась дичина. Якщо вже юзаєш поетрі (я не фанат, але!), то ним же можна й пакувати. Якщо не пакуєш, то можна було б щось полегше — tox чи nox як запускалку команд з контрольованою матрицею тестів.

P.P.P.S. І останнє. Оце python setup.py sdist bdist_wheel слід викинути у вікно в 2022 (кілька років як пора). blog.ganssle.io/...​/setup-py-deprecated.html.
Натомість треба збирати пакунки через python -m build. Це я кажу як активний учасник PyPA і мейнтейнер купи пайтон-пакунків.

P.P.S. Раджу глянути ще в бік setuptools-scm та подібних рішень. Це дозволяє мати унікальні версії на комітах, які не захардкоджені, а базуються на теґах в ґіті. Таким чином можна зробити безперервну публікацію в TestPyPI, наприклад, і мати постійну гарантію, що автоматизація для публікації продовжує працювати.

P.S. Щодо воркфлоу — там є один фатальний недолік. Якщо зрізати релізи по теґу, то виходить, що в ґіті уже буде теґ, а реліз може провалитися через лінтери. Деякі люди вважають, то можна взагалі викинути будь-яке тестування, бо коміт уже був протестований окремо іншим воркфлоу з тестами і лінтерами.
Я ж тепер схиляюся до практики використання іншого триґера — workflow_dispatch. Він додає формочку з інпутами, куди ти можеш вписати бажану версію. Тоді я просто створюю теґ прямо в CI, і коли доходить до публікації то артефакти йдуть на PyPI приблизно паралельно із тим, коли пушиться той теґ. Плюс іще можна в GitHub Releases аплоаднути їх же.
Колись у мене дійдуть руки і я перепишу packaging.python.org/...​-actions-ci-cd-workflows з цим прикладом...

@Юрій Бондаренко а можеш змінити на pypa/gh-action-pypi-publish@release/v1 в прикладах?

SHA-1 це правильно і потрібно з точки зору безпеки, і користувачам слід так і писати. Але в статті ти захардкодив старющий коміт (я так розумію це з доків ґітхаба ж?). Коли нові люди це читатимуть, то лишаться на тому старому коміті назавжди.
Саме тому в packaging.python.org/...​-actions-ci-cd-workflows я в прикладах саме гілку використовую. І в github.com/...​action-pypi-publish#usage зробив так само, але з дісклеймером.

— автор цього екшна.

Помиляєшся, в сучасному світі пакування є PEP 517, тому коректніше вже очікувати `pyproject.toml`. А при цьому може не бути ні `setup.py`, ні `setup.cfg` — зараз вони уже лиш фолбеки.

Такий принцип сплати податків наче всюди, де я бачив...

👋 давно не бачились :)

І знову ця ідіотська витівка радянських перекладачів 1970-х — thread як «потік». Ладно росіяни, а ви-то навіщо цю дурість повторили?

Я чув, що іноді нитками обзивають. Але поки ужиток не стане поширеним, будь-що звучатиме незвично 🤷.

Ти ж знаєш, що такі ініціативи багато на ентузіазмі живуть? Може долучишся? Ми от, коли перекладали PyPI, багато з друзями дебатували як перекладати деякі речі. Наприклад, фічі «yank» / «unyank», що ніяк ні з чим в голові не асоціювалися. Втім кілька днів обговорень і пинань англомовного тві+авторів відповідного пепа дозволили знайти цілком прийнятний варіант...

Одним із випробувань подібних проєктів є дотримання консистентної термінології, спільний глосарій тощо. Якщо є конкретні пропозиції й аргументи, то справді варто їх висловлювати і знаходити рішення.

Token — «жетон» — самі вигадали чи десь вже було? Виглядає дивно і незвично.

Це прямий переклад слова (поза контекстом) з англійської. Дійсно, в різних контекстах навіть на вікі термінологія з токенами різниться. Як-от «маркер» отут [1].

Мене особисто турбує зловживання неправильним перекладом слова «application», яке не є тим самим, що «додаток» (attachment, appendix), але «прикладна програма» та «застосунок» (від слова «apply» — «застосовувати»). Використання «додаток» в цьому контексті — русизм/калька [2].

[1]: uk.wikipedia.org/wiki/Маркер_доступу
[2]: web.archive.org/...​et/?view=application-term

Там у перші дні були фейки, де закликалося відключати наскрізне шифрування + більше незашифрованих метаданих збирають. Все так, просто не деталізовані всі нюанси.

До речі, ще один перелік є ось тут github.com/...​llections/made-in-ukraine