meaning of "DEPRECATION: Loading egg at .. is deprecated"?

[blsz]

Description

Why is /usr/local/Cellar/gpgme/1.22.0/lib/python3.11/site-packages/gpg-1.22.0-py3.11-macosx-11-x86_64.egg deprecated and is there anything I can do?

Expected behavior

Give a reason for the deprecation?

pip version

23.2.1

Python version

3.11

OS

MacOS 11.7.10

How to Reproduce

1. Install python with Homebrew on MacOS.
2. Install gpgme with Homebrew.
3. Run any pip3 command.

Output

Most pip3 commands include the following warning.

$ pip3 show pip
DEPRECATION: Loading egg at /usr/local/Cellar/gpgme/1.22.0/lib/python3.11/site-packages/gpg-1.22.0-py3.11-macosx-11-x86_64.egg is deprecated. pip 23.3 will enforce this behaviour change. A possible replacement is to use pip for package installation..
Name: pip
Version: 23.2.1
Summary: The PyPA recommended tool for installing Python packages.
Home-page: https://pip.pypa.io/
Author: The pip developers
Author-email: distutils-sig@python.org
License: MIT
Location: /usr/local/lib/python3.11/site-packages
Requires:
Required-by:

$ pip3 --version
pip 23.2.1 from /usr/local/lib/python3.11/site-packages/pip (python 3.11)

/usr/local/bin/pip3 -> ../Cellar/python@3.11/3.11.5/bin/pip3

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[uranusjr]

It’s literally that, loading a file in the .egg format is deprecated and the functionality will be removed in the future. You need to talk to the maintainers of the gpg package (or the package gpgme’s Homebrew distributors) to update the package to use a newer format.

[mara004]

Is there any chance of converting an existing .egg to a supported format?
(FWIW, the packages for which I get this warning are python_efl-1.26.0 and JCC-3.13, on python 3.11)

[pfmoore]

Just reinstalling should work. You might need to add the --use-pep517 option. Pip will then install the package in the modern dist-info format instead of the egg format.

[mara004]

The thing is, these packages were rather difficult to get build, and IIRC at least one of them was not installable using pip by then. Does this simply mean they are not usable anymore unless upstream projects update to a PEP 517 compatible setup?

[pfmoore]

It might be possible to convert the egg format to dist-info by moving files around, but there's no tool to do this, so you'd be on your own, reading the relevant specs and making manual changes. It's not something I'd recommend, TBH. Maybe the library developers could ship wheels? That would be another solution.

Does this simply mean they are not usable anymore unless upstream projects update to a PEP 517 compatible setup?

If the project simply won't build under --use-pep517, then yes, I'm afraid so. But many projects don't actually need any changes to build under PEP 517 - they can still be hard to build of course, if they have complex build processes, but using PEP 517 may at least not make things worse. However, if the projects do lots of build system customisations, that aren't compatible with the PEP 517 build hooks, then in that case yes, you do need the upstream project to make their build process compatible with PEP 517.

[mara004]

Thanks for the informative answer.

However, I imagine already installed egg-based modules would still be importable in python, only pip would not be able to manage (e.g. uninstall) them anymore - is that correct?

BTW, may I ask what is the matter with egg-info? Is it also covered by the deprecation? I noticed with another, supposedly PEP 517 compliant package that an egg-info dir is still generated and automatically included in the sdist.

[pfmoore]

only pip would not be able to manage (e.g. uninstall) them anymore - is that correct?

More or less, yes. But the consequences could be significant - pip won't recognise that the package is installed, so if you try to install something else that depends on it, pip could think it's not present and want to reinstall it. Essentially, "things might break" if you use pip in that environment, and we don't support it so we can't really tell you what to do if that happens.

BTW, may I ask what is the matter with egg-info?

Nothing, as such. It's not standardised data, it's setuptools-specific, so I have no idea whether it should be in a sdist or not.

The significant aspect of .egg directories is that they are a non-standard, setuptools-specific installation method, and pip has until now included special code to read that data, as a transition mechanism to avoid an abrupt change where pip stops recognising a bunch of installed packages. The deprecation is part of the process of removing that special code, and relying solely on standardised metadata (the .dist-info directory) to know what's installed.

Unlike .egginstallations, the .egg-info stuff isn't used directly by pip, so we don't need to care about it or deprecate it. I think it's related to the legacy mechanism setuptools used for editable installs (although I have no clue why it would be in a sdist in that case), but pip doesn't care how backends implement editable installs, so again, we don't need to care about .egg-info.

(Just to be clear here, all of the egg stuff is non-standard, and I'm not 100% sure on the details of how any of it works. So if any of this matters to you, I'd suggest checking the details for yourself - if you can find documentation. I don't know how well the egg stuff is documented these days).

[mara004]

Ah yes, the changelog actually tells that .egg-info metadata is not affected, linking setuptools docs:
https://github.com/pypa/pip/blob/main/NEWS.rst#232-2023-07-15