Dev Blog

Версії, збирання та розповсюдження ​

Версії, залежності та відтворюваність ​

Версія 0.1.0 відповідає правилам PEP 440. Домовленість «основна.додаткова.виправлення» описує характер змін, але інструмент не доводить сумісності API. Передреліз може мати версію 1.0.0rc1; локальна мітка має інше призначення, ніж публічний реліз. Не порівнюйте версії як звичайні рядки.

Обмеження >=2,<3 дозволяє сумісний діапазон за рішенням автора; ~=2.4 означає >=2.4,==2.*, а ~=2.4.1 – >=2.4.1,==2.4.*. Точне == фіксує одну версію прямої залежності, але не весь граф. Lock-файл зберігає вибрані транзитивні залежності та допомагає повторити середовище. Він не замінює метадані wheel.

Для uv збережіть uv.lock у Git і використовуйте uv sync --locked: невідповідність метаданим завершує команду помилкою замість мовчазного оновлення. Оновлення залежностей є окремою зміною з повторним запуском тестів. Зафіксуйте також версію Python і платформу, якщо результат від них залежить.

Редагований режим pip install -e . зручний для розробки: зміна джерел одразу доступна програмі. Проте він може приховати відсутній ресурс у wheel. Тому остаточна перевірка використовує звичайне встановлення вже зібраного артефакту.

Збирання та чисте встановлення ​

Із кореня проєкту, використовуючи його Python, виконайте:

powershell
python -m pip install -e ".[dev]"
python -m pytest -q
python -m mypy src
python -m ruff check .
python -m ruff format --check .
python -m build

python -m build створює sdist і wheel у dist/; еквівалентний спосіб збирання для uv – uv build. Перегляньте wheel як ZIP-архів: у ньому мають бути модулі, py.typed, метадані та опис точки входу. Назва файлу сама по собі не доводить повноти.

Знімок екрана

Ілюстрацію буде додано.

Рис. 16.3. Збирання sdist і wheel у терміналі

Створіть новий каталог перевірки поза коренем вихідного проєкту. Скопіюйте туди тільки wheel; команди нижче виконуються там.

powershell
python -m venv consumer
consumer\Scripts\python -m pip install --no-index `
  --no-deps units_converter-0.1.0-py3-none-any.whl
consumer\Scripts\units-convert 1.25
consumer\Scripts\units-convert --help
consumer\Scripts\units-convert -1

--no-deps доречне саме тут: пакет не має залежностей виконання. Для іншого пакета слід встановити їх із підготовленого сховища або дозволеного індексу. Запустіть pip check, перевірте шлях units_converter.__file__ і код завершення. Не додавайте src/ до PYTHONPATH під час цієї перевірки.

Знімок екрана

Ілюстрацію буде додано.

Рис. 16.4. Команда зі встановленого wheel у чистому середовищі

Для користувацької CLI-утиліти uv tool install шлях-до-wheel створює окреме середовище та надає команду. Це відрізняється від uv add, який додає залежність поточного проєкту.

Реєстр пакетів та виконуваний застосунок ​

PyPI є публічним реєстром, TestPyPI – окремим майданчиком для перевірки процесу публікації. Облікові записи, токени та вміст цих реєстрів незалежні. Публікація змінює зовнішній сервіс: спочатку перевіряють права на назву, ліцензію, вміст архівів і відсутність секретів. Токен не записують у код або звіт. Локальний wheel достатній для захисту цієї роботи.

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

PyInstaller збирає інтерпретатор, код і потрібні бібліотеки в каталог або один виконуваний файл. Він не є засобом захисту вихідного коду. Збирання для Windows виконується на Windows; сумісність перевіряють на цільовій системі. Великий розмір GUI-застосунку з Qt є очікуваним наслідком включення бібліотек.

Починайте з --onedir: так простіше побачити файли та причини помилки. --onefile розпаковує вміст під час запуску й може стартувати повільніше. --windowed приховує консоль Windows, тому додавайте його після перевірки діагностики. Для Qt існує також pyside6-deploy; це інший процес збирання, а не параметр PyInstaller. zipapp потребує встановленого сумісного Python.