leducvin
(Vincent Leduc)
September 12, 2024, 11:51am
7
Thank you for all your responses.
After reading the PEP 503 and some of pip’s source code, my impression is that it’s not by design that it works.
@sinoroc
I am surprised this works. Have you tried other installers besides pip?
It doesn’t work with uv. uv does not support the #egg fragment in the URL and removing it from the URL basically removes the package name and version information (which now both pip and uv cannot find).
It’s certainly useful for us at my organization. We use it with an internal self-hosted Gitlab instance to serve our packages via a package index. I’ve begun to use Gitlab’s package registry feature to serve wheels and do it the proper way.
I’m hesitant to formally propose it as I don’t know just how many people would actually find it useful.
If deployed on the web, such VCS links could, I suppose, prove to be a security risk. I don’t know if such links could end up on pypi or not.
I’ve found a few github issues/discussions that are somewhat related, although none of them talk about installing packages via a package index. They just consider installation of package by explicitly passing the URL to pip.
opened 03:17PM - 08 Oct 23 UTC
type: deprecation
pip has dropped support for installing `.egg` distributions when it stopped invo… king `setup.py install`.
At some point pip will abandon support for detecting and uninstalling legacy `.egg` distributions too.
If you reach this issue from the pip deprecation message, it is likely that your Python environment has distributions that have been installed with `setup.py install`, `easy_install`, or an older pip version.
**The recommended action is to uninstall the distribution and reinstall it with a recent pip.**
opened 04:03AM - 28 Oct 13 UTC
closed 09:53PM - 16 May 17 UTC
type: enhancement
auto-locked
With the demise of eggs, the "egg=" url fragment syntax is only becoming more ob… scure.
We could start supporting both "egg=" and a newer "pkg=" format, then eventually deprecate, then remove support for "egg="
Ideally, we'd do this in conjunction with setuptools.
opened 05:43AM - 04 Nov 13 UTC
type: enhancement
C: dependency resolution
C: unnamed reqs
state: awaiting PR
C: direct url
I suspect pip doesn't really need the"egg=" value (assuming we make some modific… ations)
setuptools used it in two cases:
- installing single py files (which pip doesn't support I guess?)
- installing from svn urls
pip's support is like so:
1. officially documented for vcs urls (it determines the src or build dir, depending on whether it's editable, and also determine's it's identification in the dependency resolution process.)
2. although not documented, I've seen users (including myself) tack "egg=" onto archive urls (that currently don't get their sdist filenames parsed, as you would expect (see #804), so using "egg=" for them makes them have a set build dir)
3 changes are needed, to make pip not require "egg=":
1. do away with the --no-install/--no-download "workflow" (see #906), which assumes fixed build dirs, and then drop fixed build dirs all together.
2. make it a tested feature that non-specifier requirements (i.e. vcs urls, archive urls and paths) get processed first (i.e. unpacked and have their name/version determined), so they can properly participate in the dependency resolution process. this is currently true but not very prominent in the code and not tested afaict.
3. when doing editable intalls from vcs urls, use some other approach to determine the "src" directory. Maybe just unpack it to /tmp, then determine the name, then move it back into src.
even if it turns out `#egg=`is not used in any way by pip, it may be important to document a convention as visual aid (possibly as `#pkg=`, see #1265), when the vcs url would otherwise contain no clear indication as to what it is. I know for example that various CM modules for chef and puppet make use of this indicator
Agreed – the PR I currently have open only nudges users towards the name @ ... syntax, but a full deprecation of the egg= fragment should provide the exact equivalent replacement so that a user could drop it in.
Just to clarify: the “two releases” in the top-level comment doesn’t refer to this proposal, but to the current PR open (which doesn’t remove the egg= fragment at all). The current PR only restricts the egg= fragment to valid PEP 508 project identifiers, which should have far less imp…