Skip to content

Remove the non-PEP 517 "legacy" code path for building and installing projects #6334

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
pfmoore opened this issue Mar 14, 2019 · 1 comment
Open

Remove the non-PEP 517 "legacy" code path for building and installing projects #6334

pfmoore opened this issue Mar 14, 2019 · 1 comment
Labels
C: PEP 517 impact Affected by PEP 517 processing

Comments

@pfmoore
Copy link
Member

pfmoore commented Mar 14, 2019 •
edited by sbidoul
Loading

If you reach this from the deprecation warning, see #6334 (comment) below

This is a longer-term goal, not something that can be done without a carefully managed transition, but pip should remove support for building and installing packages without using PEP 517.

Before this can be done, we need to be sure that PEP 517 support is complete, and there are no edge cases remaining of projects that cannot build with PEP 517, but need the legacy path. There is also an open question on how we provide editable install support, which is not covered by PEP 517.

I have raised this issue so that we have a central point to link to which makes it clear that this is the intended long term goal.
@pfmoore pfmoore mentioned this issue Mar 14, 2019
Merged
@cjerdonek cjerdonek added the C: PEP 517 impact Affected by PEP 517 processing label Mar 22, 2019
This was referenced Apr 23, 2019
Closed
Merged
@albireox albireox mentioned this issue Aug 9, 2019
Closed
2 tasks
@adamboche adamboche mentioned this issue Aug 30, 2019
Closed
@liZe liZe mentioned this issue Feb 5, 2020
Closed
@dstufft dstufft mentioned this issue Nov 29, 2020
Open
bonzini pushed a commit to qemu/qemu that referenced this issue May 30, 2021
@jnsnow
python: add qemu package installer
36feb2d 
Add setup.cfg and setup.py, necessary for installing a package via
pip. Add a ReST document (PACKAGE.rst) explaining the basics of what
this package is for and who to contact for more information. This
document will be used as the landing page for the package on PyPI.

List the subpackages we intend to package by name instead of using
find_namespace because find_namespace will naively also packages tests,
things it finds in the dist/ folder, etc. I could not figure out how to
modify this behavior; adding allow/deny lists to setuptools kept
changing the packaged hierarchy. This works, roll with it.

I am not yet using a pyproject.toml style package manifest, because
"editable" installs are not defined (yet?) by PEP-517/518.

I consider editable installs crucial for development, though they have
(apparently) always been somewhat poorly defined.

Pip now (19.2 and later) now supports editable installs for projects
using pyproject.toml manifests, but might require the use of the
--no-use-pep517 flag, which somewhat defeats the point. Full support for
setup.py-less editable installs was not introduced until pip 21.1.1:
pypa/pip@7a95720

For now, while the dust settles, stick with the de-facto
setup.py/setup.cfg combination supported by setuptools. It will be worth
re-evaluating this point again in the future when our supported build
platforms all ship a fairly modern pip.

Additional reading on this matter:

pypa/packaging-problems#256
pypa/pip#6334
pypa/pip#6375
pypa/pip#6434
pypa/pip#6438

Signed-off-by: John Snow <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Reviewed-by: Cleber Rosa <[email protected]>
Message-id: [email protected]
Signed-off-by: John Snow <[email protected]>
bonzini pushed a commit to qemu/qemu that referenced this issue Jun 2, 2021
@jnsnow
python: add qemu package installer
ea1213b 
Add setup.cfg and setup.py, necessary for installing a package via
pip. Add a ReST document (PACKAGE.rst) explaining the basics of what
this package is for and who to contact for more information. This
document will be used as the landing page for the package on PyPI.

List the subpackages we intend to package by name instead of using
find_namespace because find_namespace will naively also packages tests,
things it finds in the dist/ folder, etc. I could not figure out how to
modify this behavior; adding allow/deny lists to setuptools kept
changing the packaged hierarchy. This works, roll with it.

I am not yet using a pyproject.toml style package manifest, because
"editable" installs are not defined (yet?) by PEP-517/518.

I consider editable installs crucial for development, though they have
(apparently) always been somewhat poorly defined.

Pip now (19.2 and later) now supports editable installs for projects
using pyproject.toml manifests, but might require the use of the
--no-use-pep517 flag, which somewhat defeats the point. Full support for
setup.py-less editable installs was not introduced until pip 21.1.1:
pypa/pip@7a95720

For now, while the dust settles, stick with the de-facto
setup.py/setup.cfg combination supported by setuptools. It will be worth
re-evaluating this point again in the future when our supported build
platforms all ship a fairly modern pip.

Additional reading on this matter:

pypa/packaging-problems#256
pypa/pip#6334
pypa/pip#6375
pypa/pip#6434
pypa/pip#6438

Signed-off-by: John Snow <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Reviewed-by: Cleber Rosa <[email protected]>
Message-id: [email protected]
Signed-off-by: John Snow <[email protected]>
@notatallshaw notatallshaw mentioned this issue Apr 4, 2025
Closed
1 task
@sbidoul sbidoul mentioned this issue Apr 5, 2025
Merged
@sbidoul sbidoul pinned this issue Apr 5, 2025
@sbidoul
Copy link
Member

sbidoul commented Apr 23, 2025 •
edited
Loading

If you reach this issue from the deprecation warning, you can silence the message by enabling pip's PEP 517 mode, which will become the default and only mode in the future. There are several ways to do this:

  • Use the --use-pep517 option.
  • Enable it in pip.conf like so:
[install]
use_pep517 = true
  • Set a PIP_USE_PEP517=true environment variable.
  • If the warning appears for a project you control, it is recommended to add a pyproject.toml file to it, like so:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

Note it is perfectly fine to keep your setup.py file to configure setuptools for your project. For more information, consult the setuptools documentation.

Build isolation

An important difference is that pip's PEP 517 mode uses build isolation by default. This means that pip will create a temporary Python environment to build the project, whereas with the legacy behaviour the build occurs within the Python environment where pip is installed.

If your project needs specific dependencies to be pre-installed for it's build to function, it is recommended to declare them in build-system.requires in pyproject.toml.

If that is not possible, you can also use the --no-build-isolation option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: PEP 517 impact Affected by PEP 517 processing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cjerdonek @sbidoul @pfmoore