Remove additional detection of .egg packages when using the importlib.metadata backend

[sbidoul]

pip has dropped support for installing .egg-based packages when it stopped invoking setup.py install.
At some point pip will abandon support for detecting and uninstalling legacy .egg-based packages too.

If you reach this issue from the pip deprecation message, it is likely that your Python environment has packages that have been installed with setup.py install, easy_install, or an older pip version.

The recommended action is to uninstall the package and reinstall it with a recent pip.

[sbidoul]

@hanivianka have you tried the recommended action mentioned in the top post of this page?

[tahayparker]

@sbidoul has pip 24.3 been released? im tired of seeing the bright message pop up on an otherwise dark screen

[sbidoul]

@tahayparker 24.3 is planned for October 2024.

It is important that affected users resolve the warning by applying the recommendation in the first post of this page.

[loong2004]

Hello sir, could you please do me a favor? the picture below is the content of my file

I ran "python setup.py install", but after that there is something wrong. You can see it below:

What should I do? I would appreciate it for your kindness. Thank you anyway.

[anthobio23]

The problem is based on PIP updating. update to 23.3.2, rebuild the build.

first, delete the build and the dist plus the .egg.info folder.
rm -rf build dist *.egg.info

build build:

python3 -m pip install --upgrade build
python3 -m build

then, the twine:

python3 -m pip install --upgrade twine
python3 -m twine upload dist/*

view document here: Packaging Python Projects

[ichard26]

@sbidoul did you ever take a look at #12330 (comment)? Not sure what's going on with .dist-info directories in a zip file, but it is apparently triggering this deprecation.

[sbidoul]

did you ever take a look at #12330 (comment)? Not sure what's going on with .dist-info directories in a zip file, but it is apparently triggering this deprecation.

@ichard26 I could indeed reproduce by downloading a wheel, changing it's extension to .zip, and adding the zip file full path to sys.path.

At the same time I had a closer look at this egg discovery mechanism, and discovered something interesting.
Actually, setup.py install creates a .egg file in site-packages, but also adds it to easy-install.pth. So since this .egg (a zip file) is in sys.path, the importlib.metadata finder discovers it, and then the pkg_resources egg discovery mechanism disovers it... twice. So pip list prints it 3 times...

It looks like this additional .egg discovery mechanism we have was intended for situations where .egg files are found in directories that are in sys.path. But the regular setup.py install does add the egg files themselves to sys.path, so in that case our discovery mechanism is redundant.

But if I use the pkg_resources backend, it only detects eggs that are in sys.path but not eggs where only their parent directory is in sys.path.

At this point I'm not sure what to do... Maybe we should just enact this deprecation in 25.1 as we announced.

[sbidoul]

An additional interesting bit concerns uninstallation.

When a zip file is in sys.path, pip list shows it, but pip uninstall can't uninstall it, which makes sense.

Update: it depends whether the setup.py was marked zip_safe or not.

But for egg files discovered with our deprecated extended egg discovery mechanism, pip can uninstall them, but leaves the corresponding entry in easy-install.pth.

[justvanrossum]

At this point I'm not sure what to do... Maybe we should just enact this deprecation in 25.1 as we announced.

I don’t understand the details of the problem, but from my end it looks like I have a legit zip on sys.path, and this deprecation means I won’t be able to use pip for the purpose I need it to, due to this false positive in the egg detection.

[sbidoul]

@justvanrossum I agree it is a problem we need to address.

Would it be possible for you to run pip list and tell me if you see your zip package name twice?

[justvanrossum]

Would it be possible for you to run pip list and tell me if you see your zip package name twice?

Yes: every package inside the zip is indeed listed twice.

[sbidoul]

Since the deprecation message is showing false positives, and apparently reveals a problem with this additional eggs discovery code path, I'll move forward and remove it in 25.1 as announced.

[sbidoul]

@justvanrossum thanks a lot for reporting. You will not see the warning anymore in 25.1, and duplicates in pip list will be resolved. If you wish, you can test #12308.

[justvanrossum]

You will not see the warning anymore in 25.1, and duplicate in pip list will be resolved. If you wish, you can test #12308.

Hm, I still see the warning when I install from that PR's branch. Assuming the following is correct to achieve that:

pip install -U git+https://github.com/sbidoul/pip.git@rm-find-eggs

[sbidoul]

That is weird. Because if we trust the diff displayed by GitHub for that PR, the code that emits that warning is gone.

[justvanrossum]

That is weird. Because if we trust the diff displayed by GitHub for that PR, the code that emits that warning is gone.

Somehow installing pip directly from that fork's branch didn't quite work (I tried several times). However, if I clone the fork locally, and switch to the rm-find-eggs branch, and install pip from that local copy, I can confirm that the warning is gone. Thank you very much!