-
Notifications
You must be signed in to change notification settings - Fork 3k
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.
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
Deprecate pip install --editable
calling setup.py develop
#11457
Comments
This is complicated by the fact that https://numpy.org/doc/stable/reference/distutils_status_migration.html |
Adding a cross-reference to the idea of dropping support for this, starting Python 3.12+ (circa #8102 (comment)). This also makes sense since we'd stop install setuptools by default in ensurepip starting with that Python version, and get-pip.py as well, I imagine. |
Is it worth adding a deprecation message for the |
Is here the correct place for the deprecation warning? pip/src/pip/_internal/req/req_install.py Lines 829 to 842 in 2a0acb5
|
I think so, either this or inside |
@edmorley I personally think so yes. A question I have is if the deprecation message should mention that |
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
I've opened #12830 to add the deprecation warning for the |
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Deprecates `pip install --editable` falling back to `setup.py develop` when using a setuptools version that does not support PEP 660 (setuptools v63 and older). See: https://peps.python.org/pep-0660/ https://setuptools.pypa.io/en/latest/history.html#v64-0-0 Closes pypa#11457.
Nice work yall ♥ |
I’ll do the edit. |
…l --editable calling setup.py develop pypa/pip#11457
Updates the requirements on [pip](https://github.com/pypa/pip) to permit the latest version. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/pypa/pip/blob/main/NEWS.rst">pip's changelog</a>.</em></p> <blockquote> <h1>24.2 (2024-07-28)</h1> <h2>Deprecations and Removals</h2> <ul> <li>Deprecate <code>pip install --editable</code> falling back to <code>setup.py develop</code> when using a setuptools version that does not support :pep:<code>660</code> (setuptools v63 and older). (<code>[#11457](pypa/pip#11457) <https://github.com/pypa/pip/issues/11457></code>_)</li> </ul> <h2>Features</h2> <ul> <li> <p>Check unsupported packages for the current platform. (<code>[#11054](pypa/pip#11054) <https://github.com/pypa/pip/issues/11054></code>_)</p> </li> <li> <p>Use system certificates <em>and</em> certifi certificates to verify HTTPS connections on Python 3.10+. Python 3.9 and earlier only use certifi.</p> <p>To revert to previous behaviour, pass the flag <code>--use-deprecated=legacy-certs</code>. (<code>[#11647](pypa/pip#11647) <https://github.com/pypa/pip/issues/11647></code>_)</p> </li> <li> <p>Improve discovery performance of installed packages when the <code>importlib.metadata</code> backend is used to load distribution metadata (used by default under Python 3.11+). (<code>[#12656](pypa/pip#12656) <https://github.com/pypa/pip/issues/12656></code>_)</p> </li> <li> <p>Improve performance when the same requirement string appears many times during resolution, by consistently caching the parsed requirement string. (<code>[#12663](pypa/pip#12663) <https://github.com/pypa/pip/issues/12663></code>_)</p> </li> <li> <p>Minor performance improvement of finding applicable package candidates by not repeatedly calculating their versions (<code>[#12664](pypa/pip#12664) <https://github.com/pypa/pip/issues/12664></code>_)</p> </li> <li> <p>Disable pip's self version check when invoking a pip subprocess to install PEP 517 build requirements. (<code>[#12683](pypa/pip#12683) <https://github.com/pypa/pip/issues/12683></code>_)</p> </li> <li> <p>Improve dependency resolution performance by caching platform compatibility tags during wheel cache lookup. (<code>[#12712](pypa/pip#12712) <https://github.com/pypa/pip/issues/12712></code>_)</p> </li> <li> <p><code>wheel</code> is no longer explicitly listed as a build dependency of <code>pip</code>. <code>setuptools</code> injects this dependency in the <code>get_requires_for_build_wheel()</code> hook and no longer needs it on newer versions. (<code>[#12728](pypa/pip#12728) <https://github.com/pypa/pip/issues/12728></code>_)</p> </li> <li> <p>Ignore <code>--require-virtualenv</code> for <code>pip check</code> and <code>pip freeze</code> (<code>[#12842](pypa/pip#12842) <https://github.com/pypa/pip/issues/12842></code>_)</p> </li> <li> <p>Improve package download and install performance.</p> <p>Increase chunk sizes when downloading (256 kB, up from 10 kB) and reading files (1 MB, up from 8 kB). This reduces the frequency of updates to pip's progress bar. (<code>[#12810](pypa/pip#12810) <https://github.com/pypa/pip/issues/12810></code>_)</p> </li> <li> <p>Improve pip install performance.</p> <p>Files are now extracted in 1MB blocks, or in one block matching the file size for smaller files. A decompressor is no longer instantiated when extracting 0 bytes files, it is not necessary because there is no data to decompress. (<code>[#12803](pypa/pip#12803) <https://github.com/pypa/pip/issues/12803></code>_)</p> </li> </ul> <h2>Bug Fixes</h2> <ul> <li>Set <code>no_color</code> to global <code>rich.Console</code> instance. (<code>[#11045](pypa/pip#11045) <https://github.com/pypa/pip/issues/11045></code>_)</li> <li>Fix resolution to respect <code>--python-version</code> when checking <code>Requires-Python</code>. (<code>[#12216](pypa/pip#12216) <https://github.com/pypa/pip/issues/12216></code>_)</li> <li>Perform hash comparisons in a case-insensitive manner. (<code>[#12680](pypa/pip#12680) <https://github.com/pypa/pip/issues/12680></code>_)</li> <li>Avoid <code>dlopen</code> failure for glibc detection in musl builds (<code>[#12716](pypa/pip#12716) <https://github.com/pypa/pip/issues/12716></code>_)</li> <li>Avoid keyring logging crashes when pip is run in verbose mode. (<code>[#12751](pypa/pip#12751) <https://github.com/pypa/pip/issues/12751></code>_)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/pypa/pip/commit/97146c7f4cd85551f3dc261830a57f304e43c181"><code>97146c7</code></a> Bump for release</li> <li><a href="https://github.com/pypa/pip/commit/ef81b2eafd390fb56f62930dcd74f6e4580093e0"><code>ef81b2e</code></a> Update AUTHORS.txt</li> <li><a href="https://github.com/pypa/pip/commit/350a0570a88b6c0d13c68f81ac08dc64f954cadf"><code>350a057</code></a> Bump the github-actions group with 2 updates (<a href="https://redirect.github.com/pypa/pip/issues/12876">#12876</a>)</li> <li><a href="https://github.com/pypa/pip/commit/184390f4f2cde0316801eb701f49dda4f7a9a6ac"><code>184390f</code></a> Update dependabot.yml to bump group updates (<a href="https://redirect.github.com/pypa/pip/issues/12572">#12572</a>)</li> <li><a href="https://github.com/pypa/pip/commit/48917f1c0375496058d677f652a90de6bee4dc8c"><code>48917f1</code></a> Merge pull request <a href="https://redirect.github.com/pypa/pip/issues/12875">#12875</a> from hellozee/fix-unit-test</li> <li><a href="https://github.com/pypa/pip/commit/dd85c28464dbfc9b3a53c885a41c209e4700ad2d"><code>dd85c28</code></a> Fix invalid origin test to check all the logged messages</li> <li><a href="https://github.com/pypa/pip/commit/203780b5d167c4d01c55df7adc91d5ad1a0563aa"><code>203780b</code></a> Merge pull request <a href="https://redirect.github.com/pypa/pip/issues/12865">#12865</a> from pradyunsg/better-exception-handling-around-sel...</li> <li><a href="https://github.com/pypa/pip/commit/e50314134886d5eb5b650b3ce95abaafcb6dce10"><code>e503141</code></a> Properly mock <code>_self_version_check_logic</code></li> <li><a href="https://github.com/pypa/pip/commit/3518d3293445ad43eedba116b6182185c03abda3"><code>3518d32</code></a> Rework how <code>--debug</code> is handled in <code>main</code></li> <li><a href="https://github.com/pypa/pip/commit/be21d82e4362c00aab451ef1cf212d9a62f8e58e"><code>be21d82</code></a> Move exception suppression to cover more of self-version-check logic</li> <li>Additional commits viewable in <a href="https://github.com/pypa/pip/compare/24.1.1...24.2">compare view</a></li> </ul> </details> <br /> You can trigger a rebase of this PR by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> > **Note** > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.
Does this mean that |
@timmc-edx The key phrase is that things will break if your package is already broken when the modern editable install mechanism is used. The breakage possible with pip 25 is that the automatic fallback that keeps those packages working will be removed.
I guess a valid third "solution" is simply to do nothing. If the package functions correctly under the modern editable install mechanism (you can verify that by forcing the modern mechanism via In essence, "it depends" is the answer. If you can, the pip team strongly recommends migrating to the supported and standardized solutions, but doing nothing can be a valid path forward. Also, older versions of pip can be used when needed. Footnotes
|
Comment from a side. I am really sorry for it to be a long message, I just wanted to provide a bit more context. So for those who would like to get the gist of it here is TL;DR;. TL;DR; while I would love to see the legacy support removed in 25.0. I think it would be worth to think about one more escalation step that will allow package developers to use "user pressure" to make sure their dependencies are also migrated to modern standards - namely to change current warnings into error and allow the user to "opt-in" to use the old mechanism for some time. I am not sure - maybe it is already planned - after reading very carefully the entirely thread I think we are going to go straight from "warning" to "remove support" - but I could have missed it or misunderstand it, so wanted to raise it here. I think this would be the "right escalation path" - for example change to opt-in in 24.3 and complete removal in 25.0 (or maybe 25.1 or 25.2 or even do it with 25.0 (opt-in) followed by 26.0 (removal) scenario. Similar approaches were taken in the past in Why I think it would be good to follow this path?Because there is only as much package developer can do as to convert their own package to use modern standards (for example we did it in Airflow with apache/airflow#36537 for example. But when you have a lot of dependencies, convincing them and their dependencies and their dependencies to modernize is a long process and unless there is a really strong incentive, you have very limited impact on that. I think in many cases 'supply chain' issues are "people's/maintainers" bound not "tooling bound" and the more we enable the right people to communicate and teach each other - the better. For example push-down the efforts to modernize things where higher-layer dependencies will fill incentive and need to reach out to the 'lower layer" dependencies in dependency tree, the more effective such transition will be. The problem with creating thie incentive is that currently the "warnings" are mostly for "end-users". While maintainers can fix their own project setup, they are rarely aware that any of their dependencies (including transitive ones) has such problems. Mainly because in most cases the pre-packaged .whl files are available, there is no need to build the packages when you install even 100s of your dependencies - especially if you are using modern distros. And you will not even be aware how many and which of your dependencies need to be reached out to (and maybe even helped with) to fix it. Because often times users who experience that (for example using some old distros or requiring for some reasons older versions of those packages) just plainly ignore the warnings and you are not even aware of it as package maintainer. So, what will it change if we turn the warnings into errors and allow the user to "opt-in" to remove them.IMHO - a lot. What will happen in most cases, the users's installation wil break, they will see the error message that will suggest them to raise an issue to the package that is problematic, or switch to the "opt-in" - but that one could clearly say - "this will stop working on that date or version of
So, summarising - I think it would be great to consider one step escalation process (error out with opt-in to enable old behaviour back) as this will give a chance for this kind of "trickle-down" effort to be less disruptive. |
@potiuk What you are saying makes sense for wider-reaching changes like the historic switch from the legacy resolver, however, I don't think it's as applicable here. Since:
In general, I would like us to enable build isolation by default soon (whilst still allowing a way to opt out, like uv does) - I think in fact that change doesn't need to wait for this one to be complete. I've just added a comment about that here: |
I can't edit the post, but just as a friendly reminder to all, the What's tricky here is that pip defaults to using the legacy You can keep your |
What you wrote makes perfect sense. Thanks for explaining in detail. Yeah - what you describe makes perfect sense and my concerns are addressed. Going with straight removal should be fine. |
FIX Fix the pip warning explained here: pypa/pip#11457 By following this procedure: pypa/pip#11457 (comment)
There is now a standardized mechanism for an installer like pip to request an editable install of a project.
pip is transitioning to using this standard only instead of invoking the deprecated
setup.py develop
command.What's being deprecated?
There is a standardized mechanism (called PEP 660) for an installers to request an editable install of a project. The benefit of this modern mechanism is that it allows projects packaged using other tools (formally called "build backends") such as Hatch and Poetry to support editable installs.
Since pip 21.3, pip has switched to using this mechanism where possible. Now the pip project seeks to deprecate and eventually remove the old and setuptools-specific fallback to running
setup.py develop
when apyproject.toml
is not present or the PEP 660 mechanism is unsupported for some reason.Some historical context if you're interested
Historically, there was no standard way for installers like pip to request an editable install of a project. Thus, the
-e
/--editable
option was implemented as a wrapper over thesetup.py develop
command. Using this method, only setuptools projects could use editable installs. PEP 660 defines an interface which build backends can implement in order to support editable installs.If you are still interested and want more details, they are available on @ichard26's blog post on the changes in pip 24.2. You should read this issue first though!
How will this affect my project?
If you have received a deprecation warning about a legacy editable install, pip is using the legacy
setup.py develop
method for performing an editable installation of your project. In practice, this usually means one of two things:pyproject.toml
file doesn’t exist at all, thus pip will opt-out of the modern mechanism and usesetup.py develop
[build-system].requires
field) is too old and doesn’t support PEP 660, i.e. anything older than setuptools 64.0.0The current plan is that support for legacy editable installs will be entirely removed in pip 25.0 (Q1 2025). If your package doesn't not support or function correctly under an editable install using the modern mechanism,
pip install -e
will break starting with pip 25.0.What should I do?
There are a couple of choices:
Add a
pyproject.toml
to your project, making sure the[build-system]
section requiressetuptools >= 64
, as well as other libraries required to build your project (the equivalent of setuptools'setup_requires
parameter). A basic example is included below:Alternatively, enable the
--use-pep517
pip option, possibly with--no-build-isolation
. The--use-pip517
flag will force pip to use the modern mechanism for editable installs.--no-build-isolation
may be needed if your project has build-time requirements beyondsetuptools
andwheel
. By passing this flag, you are responsible for making sure your environment already has the required dependencies to build your package. Once the legacy mechanism is removed,--use-pep517
will have no effect and will essentially be enabled by default in this context.Tip
If the resulting installation does not behave correctly, you may want to try the
--config-setting editable_mode=compat
pip option. Please consult the setuptools documentation for more information.Tip
Which solution you choose to use depends on the project, but option one is recommended as there are other benefits to adding a
pyproject.toml
file. For example, you can declare your project metadata inpyproject.toml
. If your project already works fine using the modern mechanism, option two is an acceptable way to silence the deprecation warning in the meanwhile.The text was updated successfully, but these errors were encountered: