Должен ли я собрать пакет с использованием PEP 517

PEP 517 — это стандартный шаблон сборки для пакетов Python, необходимый для межсистемных сборок пакетов.

PEP 517 — это предложение по улучшению Python (PEP), которое определяет стандартный интерфейс сборки для пакетов Python. Предложение определяет требования к инструменту сборки, которые позволяют сборщикам пакетов использовать любую систему сборки, которую они предпочитают, обеспечивая при этом согласованный и надежный процесс сборки. В этой статье мы рассмотрим подробнее посмотрите на PEP 517, что это такое, когда его использовать и когда не использовать, а также несколько примеров.

Что такое PEP 517?

PEP 517 разработан, чтобы облегчить разработчикам создание, распространение и установку пакетов Python. Рассматривайте это как стандартный набор правил для разработки пакета, чтобы совместимость пакета не вызывала особых проблем. В предложении указывается, что инструменты сборки должны предоставлять стандартизированный бэкенд сборки, который может использоваться такими инструментами упаковки, как pip или setuptools. Цель PEP 517 — упростить разработчикам создание высококачественных и надежных пакетов Python, которые можно легко установить в любой системе.

Когда использовать PEP 517?

PEP 517 наиболее полезен для разработчиков, которым необходимо создавать сложные межплатформенные пакеты Python. Если у вас мало времени, то есть ваш ответ. Если вы создаете простой пакет с простым процессом сборки, вам может не понадобиться использовать PEP 517. Однако, если для вашего пакета требуются более продвинутые функции сборки, такие как компиляция собственных расширений или сборка нескольких версий вашего пакета для разных платформ, используйте PEP 517. может сделать вашу жизнь намного проще. Рекомендовал бы я практиковать PEP 517, да! всегда склоняйтесь к стандарту, но не позволяйте ему стать препятствием в вашем прогрессе. Продолжайте двигаться.

PEP 517 также полезен, если вы хотите использовать инструмент сборки, отличный от setuptools, который является инструментом сборки по умолчанию для пакетов Python. Если вы предпочитаете использовать другую систему сборки, такую как CMake или Meson, вы можете использовать PEP 517, чтобы определить стандартизированную серверную часть сборки, которая работает с вашим предпочтительным инструментом сборки.

Когда не использовать PEP 517?

Честно говоря, никогда не бывает ситуаций, когда нельзя не использовать PEP 517, но давайте переформулируем его, поскольку PEP 517 может быть необходимым для простых пакетов Python с простым процессом сборки.

Если ваш пакет не требует каких-либо расширенных функций сборки
вы довольны использованием setuptools в качестве инструмента сборки, возможно, вам не понадобится использовать PEP 517.
если вы создаете пакет, предназначенный только для определенной платформы или среды.

вам может не понадобиться использовать PEP 517. Например, если вы собираете пакет для определенного дистрибутива Linux, вы можете использовать инструменты упаковки этого дистрибутива для создания пакета, а не использовать PEP 517.

Примеры

Давайте рассмотрим несколько примеров того, когда следует использовать PEP 517, а когда нет.

Пример 1: простой пакет

Предположим, вы создаете простой пакет Python, который не требует каких-либо расширенных функций сборки. В этом случае вам, вероятно, не нужно использовать PEP 517. Вы можете просто использовать setuptools в качестве инструмента сборки и создать файл setup.py для определения вашего пакета. Вот пример:

# Content of setup.py
from setuptools import setup, find_packages

setup(
    name='my_simple_package',
    version='0.1',
    packages=find_packages(),
    install_requires=[
        'requests',
    ],
)

Этот файл setup.py определяет простой пакет Python с именем my_simple_package, который зависит от библиотеки requests. Чтобы собрать пакет, вы можете запустить следующую команду:

python setup.py sdist bdist_wheel

Это создаст исходный дистрибутив и дистрибутив бинарного колеса вашего пакета, которые можно легко установить с помощью pip.

Вот как будет выглядеть вывод —

me@mymachine:~/workspace/packaging_example$ . /home/m/.cache/pypoetry/virtualenvs/packaging-Aqqc-AtY-py3.10/bin/activate
(packaging-py3.10) m@mymachine:~/workspace/packaging_example$ python setup.py sdist bdist_wheel
running sdist
running egg_info
creating my_simple_package.egg-info
writing my_simple_package.egg-info/PKG-INFO
writing dependency_links to my_simple_package.egg-info/dependency_links.txt
writing requirements to my_simple_package.egg-info/requires.txt
writing top-level names to my_simple_package.egg-info/top_level.txt
writing manifest file 'my_simple_package.egg-info/SOURCES.txt'
reading manifest file 'my_simple_package.egg-info/SOURCES.txt'
writing manifest file 'my_simple_package.egg-info/SOURCES.txt'
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
creating my_simple_package-0.1
creating my_simple_package-0.1/my_simple_package.egg-info
copying files to my_simple_package-0.1...
copying pyproject.toml -> my_simple_package-0.1
copying setup.py -> my_simple_package-0.1
copying my_simple_package.egg-info/PKG-INFO -> my_simple_package-0.1/my_simple_package.egg-info
copying my_simple_package.egg-info/SOURCES.txt -> my_simple_package-0.1/my_simple_package.egg-info
copying my_simple_package.egg-info/dependency_links.txt -> my_simple_package-0.1/my_simple_package.egg-info
copying my_simple_package.egg-info/requires.txt -> my_simple_package-0.1/my_simple_package.egg-info
copying my_simple_package.egg-info/top_level.txt -> my_simple_package-0.1/my_simple_package.egg-info
Writing my_simple_package-0.1/setup.cfg
creating dist
Creating tar archive
removing 'my_simple_package-0.1' (and everything under it)
running bdist_wheel
running build
/home/me/.cache/pypoetry/virtualenvs/packaging-Aqqc-AtY-py3.10/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
installing to build/bdist.linux-x86_64/wheel
running install
running install_egg_info
Copying my_simple_package.egg-info to build/bdist.linux-x86_64/wheel/my_simple_package-0.1-py3.10.egg-info
running install_scripts
creating build/bdist.linux-x86_64/wheel/my_simple_package-0.1.dist-info/WHEEL
creating 'dist/my_simple_package-0.1-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
adding 'my_simple_package-0.1.dist-info/METADATA'
adding 'my_simple_package-0.1.dist-info/WHEEL'
adding 'my_simple_package-0.1.dist-info/top_level.txt'
adding 'my_simple_package-0.1.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel

Пример 2. Сборка кроссплатформенного пакета (PEP 517)

Предположим, вы создаете более сложный пакет Python, который требует компиляции собственных расширений и создания нескольких версий вашего пакета для разных платформ. В этом случае вы можете использовать PEP 517 для определения стандартизированного бэкэнда сборки, который работает с вашей предпочтительной системой сборки.

Например, предположим, что вы создаете пакет, который:

включает расширение C
и вы предпочитаете использовать систему сборки Meson.

В этом случае вы можете определить файл setup.cfg, указывающий серверную часть сборки Meson, используя PEP 517. Вот пример:

[metadata]
name = my_package
version = 0.1.0
author = My Name
author_email = [email protected]
description = A simple Python package that prints "Hello, world!"
long_description = file: README.md
long_description_content_type = text/markdown
license = MIT
classifiers =
    Programming Language :: Python :: 3
    License :: OSI Approved :: MIT License
    Operating System :: OS Independent

[options]
packages = find:
install_requires =
    # None

[options.packages.find]
where = my_package

[build-system]
requires = ["setuptools>=38.6.0", "wheel", "meson>=0.57.0", "ninja>=1.10.0.post1"]
build-backend = "setuptools.build_meta"

[tool.meson]
# Specify build options here

Этот файл setup.cfg определяет требования к сборке пакета, включая setuptools, wheel, Meson и Ninja. Он также указывает, что setuptools следует использовать в качестве бэкенда сборки. Затем вы можете определить параметры сборки в разделе [tool.meson] файла.

Вам также понадобится несколько других файлов, чтобы убедиться, что процесс работает гладко. Каталог будет выглядеть примерно так. package2 должен оставаться одинаковым для 2 уровней каталога. Я буду использовать package2 в качестве имени пакета.

package2/
    package2/
        __init__.py
        my_module.py
    README.md
    setup.cfg
    pyproject.toml

Вот краткий обзор каждого из файлов в этой структуре:

package2/package2/__init__.py: это пустой файл, который помечает каталог package2 как пакет Python.
package2/package2/my_module.py: это простой модуль Python, определяющий функцию my_function.
README.md: Это файл, содержащий базовую документацию по пакету.
setup.cfg: Это файл конфигурации, содержащий метаданные о пакете, такие как его имя, версия, автор и лицензия.
pyproject.toml: Это файл конфигурации, который указывает, как должен быть собран пакет.

мой_модуль.py

def my_function():
    return "Hello, world!"

README.md

# My Package

This is a simple Python package that provides a function to print "Hello, world!".

pyproject.toml

Примечание о pyproject.toml. Если вы уже используете poetry, вам не нужно беспокоиться об изменении существующего pyproject.toml..

[build-system]
requires = [
    "setuptools >= 40.8.0",
    "wheel"
]
build-backend = "setuptools.build_meta"

Еще одно замечание: если вы используете Ubuntu, обязательно установите virtualenv..

Теперь вы готовы собрать свой пакет с помощью PEP 517. Чтобы собрать свой пакет с помощью этого файла setup.cfg, вы можете использовать следующую команду:

pip install build
python -m build

Что должно давать вывод, например

(packaging2-py3.10) me@mymachine:~/workspace/packaging2$ python -m build
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (poetry-core)
* Getting build dependencies for sdist...
* Building sdist...
* Building wheel from sdist
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (poetry-core)
* Getting build dependencies for wheel...
* Building wheel...

Альтернативным и более простым способом сделать то же самое будет поэзия, если вы уже используете ее.

Запустите команду poetry build, как показано ниже.

(packaging2-py3.10) me@mymachine:~/workspace/packaging2$ poetry build
Building packaging2 (0.1.0)
  - Building sdist
  - Built packaging2-0.1.0.tar.gz
  - Building wheel
  - Built packaging2-0.1.0-py3-none-any.whl

Пример 3: пакет дистрибутива

Предположим, вы создаете пакет, предназначенный для распространения как части дистрибутива Linux. В этом случае вам может не понадобиться использовать PEP 517. Вместо этого вы можете использовать инструменты упаковки, предоставляемые дистрибутивом, для создания пакета.

Например, предположим, что вы создаете пакет для Ubuntu. Вы можете создать пакет Debian с помощью инструмента debuild, предоставляемого системой пакетов Ubuntu. Вот пример:

Вы можете установить эти пакеты с помощью следующей команды:

sudo apt-get install build-essential devscripts dh-python python-all-dev python-stdeb

Затем перейдите в корневой каталог вашего пакета Python. setup.py — это тот же файл, который мы видели ранее в этой статье. Теперь выполните следующую команду, чтобы создать исходный пакет Debian:

python setup.py --command-packages=stdeb.command sdist_dsc

Это создаст исходный дистрибутив вашего пакета и соответствующий исходный пакет Debian в каталоге deb_dist.

Наконец, вы можете использовать debuild для сборки бинарного пакета Debian из пакета с исходным кодом. Выполните следующую команду:

cd deb_dist/<package-name>-<version>
debuild -us -uc -i -b

Это скомпилирует и упакует ваш пакет Python в двоичный пакет Debian. После сборки пакета его можно установить с помощью инструмента dpkg:

sudo dpkg -i <package-name>_<version>_all.deb

При этом будут использоваться инструменты упаковки Ubuntu для создания пакета Debian из вашего пакета Python. В течение всего этого процесса мы фактически никогда не использовали PEP 517, потому что в этом просто не было необходимости.

Заключение

PEP 517 предоставляет стандартный интерфейс сборки для пакетов Python, позволяя разработчикам использовать любую систему сборки, которую они предпочитают, обеспечивая при этом согласованный и надежный процесс сборки. Хотя PEP 517 наиболее полезен для сложных межплатформенных пакетов, он может не понадобиться для простых пакетов или пакетов, предназначенных только для определенной платформы или среды. Понимая, когда использовать PEP 517, а когда нет, вы можете быть уверены, что ваши пакеты Python созданы надежно и эффективно.

Для моего другого спасательного контента, пожалуйста, ознакомьтесь

Все, что вам нужно знать о строках документации
Строки документации являются важным аспектом написания хорошо документированного кода Python. Они документируют цель, аргументы и…levelup.gitconnected.com

Как запустить собственную модель LLaMA
Вес модели LLaMA доступен в Интернете на различных веб-сайтах. Это незаконно, но я делюсь просто «Как…levelup.gitconnected.com

6 методов проведения линейной регрессии в Python
Обобщенные линейные модели (GLM) лежат в основе большинства моделей, основанных на регрессииmedium.com

Не забудьте подписаться, поставить лайк и поделиться статьей. Спасибо!

🔔 хлопать| Подписаться | Подписаться🔔

Стать участником по моей ссылке: https://ithinkbot.com/membership

Должен ли я собрать пакет с использованием PEP 517 — и как