Remove the non-PEP 517 "legacy" code path for building and installing projects #6334
Labels
C: PEP 517 impact
Affected by PEP 517 processing
Comments
This was referenced Apr 23, 2019
2 tasks
bonzini
pushed a commit
to qemu/qemu
that referenced
this issue
May 30, 2021
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 <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-11-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
bonzini
pushed a commit
to qemu/qemu
that referenced
this issue
Jun 2, 2021
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 <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-11-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: