Итак, я пытаюсь создать новый пакет Python, следуя этому руководству: https://packaging.python.org/en/latest/tutorials/packaging-projects/
Как говорится в инструкции - в моей pyproject.toml у меня должна быть такая структура:
[project]
name = "example_package_YOUR_USERNAME_HERE"
version = "0.0.1"
authors = [
{ name = "Example Author", email = "[email protected]" },
]
description = "A small example package"
но когда я создал этот файл с помощью poetry init, у меня была такая структура:
[tool.poetry]
name = "example_package_YOUR_USERNAME_HERE"
version = "0.0.1"
authors = [
{ name = "Example Author", email = "[email protected]" },
]
description = "A small example package"
Основное различие между ними — заголовки project и tool.poetry для разделов.
Я также вижу, что poetry ничего не может сделать с проектом, когда в [tool.poetry] нет pyproject.toml
pyproject.toml? И что должно содержать, что, если я должен держать оба?[tool.poetry] - значит, мне нужно следовать тем же правилам для именования разделов [project]? Значит, [project.urls] будет переименован в [tool.poetry.urls]?[build-system] с poetry-core на setuptools — хорошая идея? Или оставить poetry-core?Раздел [project] является обязательным в pyproject.toml. Если запись отсутствует, инструмент сборки (определенный в разделе [build-system]) должен добавить ее динамически. Я думаю, это именно то, что делает poetry.
Из документации:
Ключи, определенные в этой спецификации, ДОЛЖНЫ находиться в таблице с именем [project] в pyproject.toml. Никакие инструменты не могут добавлять в эту таблицу ключи, которые не определены данной спецификацией. Для инструментов, желающих сохранить свои собственные настройки в pyproject.toml, они могут использовать таблицу [tool], как определено в спецификации объявления зависимостей сборки. Отсутствие таблицы [project] неявно означает, что серверная часть сборки будет динамически предоставлять все ключи.
Так что вам не нужен [project], пока вы используете poetry. Если вы измените систему сборки, вы должны преобразовать файл pyproject.toml в соответствие с PEP 621.
1. Какая разница между этими двумя?
Раздел [проект] стандартизирован (он же PEP-621 ). Но Поэзия старше создания этого стандарта, поэтому она началась с использования собственного раздела [tool.poetry]. Poetry планирует добавить поддержку стандартизированного [project] (см. python-poetry/poetry/issues/3332 и python-poetry/roadmap/issues/3), но это требует времени.
Различия между ними довольно малы, в основном это разные обозначения для одних и тех же метаданных пакета.
2. Должен ли я иметь только один или оба одновременно в моем pyproject.toml? И что должно содержать, что, если я должен держать оба?
У вас должен быть только один. Вы должны выбрать серверную часть сборки. Если ваш бэкенд сборки poetry-core, вам нужен раздел [tool.poetry]. Если вы выберете серверную часть сборки, для которой требуется [project] (как в случае с setuptools), то это то, что вам нужно.
3. Если должно быть только [tool.poetry] - значит, мне нужно следовать тем же правилам для [project] именования разделов? Значит, [project.urls] будет переименован в [tool.poetry.urls]?
Это не совсем однозначный эквивалент, есть некоторые отличия. Следуйте документации Poetry , если вы используете Poetry. Или спецификацию [проекта], если вы используете что-то другое (setuptools и т. д.).
4. Что лучше всего подходит для будущей публикации на PyPI? Или разницы нет?
Большой разницы нет. Вы можете возразить, что лучше выбрать серверную часть сборки, соответствующую стандарту [project], но на самом деле это не то, на чем вы должны основывать свой выбор. Есть много других критериев, на которых вы должны основывать свой выбор.
Например:
5. Является ли изменение [build-system] с poetry-core на setuptools хорошей идеей? Или оставить poetry-core?
Поэзия «инструмент рабочего процесса разработки» не позволяет использовать какой-либо другой бэкэнд сборки, кроме poetry-core. Поэтому, если вы хотите продолжать использовать Poetry для своего проекта, у вас нет другого выбора, кроме как продолжать использовать poetry-core в качестве бэкенда сборки.