|
|
Log in / Subscribe / Register

PEP517

PEP517

Posted May 22, 2025 12:09 UTC (Thu) by zahlman (guest, #175387)
In reply to: PEP517 by sam_c
Parent article: Recent disruptive changes from Setuptools

>The Python ecosystem is moving towards PEP517 for packaging which formalises how one creates and then installs a wheel.

PEP 517 isn't so much about defining the process, as it is about providing an interface that allows installers to automate it. `pyproject.toml` allows you to specify a build backend, but the default is still Setuptools, and pip will be able to install practically any legacy package that was designed for the `setup.py install` workflow. It's *that workflow itself* that's being deprecated (https://blog.ganssle.io/articles/2021/10/setup-py-depreca...); but the existing `setup.py` doesn't need modification. Setuptools implements its part of the PEP 517 contract basically by simulating what `setup.py install` would do; and it will continue to work that way with perhaps some internal simplification.

>This intentionally doesn't handle the case where you need to install non-Python data files and friends.

I don't follow. The wheel format explicitly provides for a folder of data files, which has subfolders for several different standard install locations (https://packaging.python.org/en/latest/specifications/bin...); and Setuptools explicitly provides configuration options to say what data files to include in the wheel and which subfolder they belong to (https://setuptools.pypa.io/en/latest/userguide/datafiles....). I'm not sure what it means for a data file to be "non-Python"; if your Python project has a C extension and a data file, neither the wheel format, nor Setuptools nor the installer will care whether the Python code reads the data or the C code does (or both).

But yes, some developers will be disrupted if they're using `setup.py` from higher level tooling, or want to install files to places outside of any Python environment (like /etc or something). Or I guess if they're trying to use Setuptools to make a .rpm or .deb etc. Eventually that will all go away.

But alternatives exist; and this is anyway much less disruptive than an end-user's install failing because a transitive dependency couldn't be built from source locally.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds