version 0.45: Metadata-Version change to 2.4 while converting breaks compatibility with Artifactory

[AndreaCensi]

This change:

c81f5c9#diff-94823ead5c1b659f5e4ce678faeecfae04532b1b67982adb50228830c094fe50R90

replaces Metadata-Version with 2.4 when converting wheels.

This breaks compatibility with Artifactory.

Artifactory knows up to 2.3, and refuses to process 2.4, even though it should, according to spec, accept a minor change in the spec.

Is there a workaround to set a specific Metadata-Version?

(also, should the Metadata-Version be changed at all when converting?)

[agronholm]

Workaround: unpack the wheel, run a search/replace on the Metadata-Version header, and wheel pack it again. Or use an older version of wheel.

The bigger question is: why are you converting from eggs in the first place? Where are those eggs coming from? The format has been obsolete for years.

[AndreaCensi]

@agronholm

Some time I need to create packages that only include *.pyc when I don't want to distribute the source code; for example for distributing the solution checker for programming assignments that needs to contain a valid solution for comparing results.

This is the only way I managed to do it:

python setup.py bdist_egg --dist-dir dist --exclude-source-files 
python -m wheel convert dist/*.egg -d dist 

[agronholm]

If you have a complicated build process, you might be better off with Hatchling or PDM as your build back-end, rather than setuptools. They let you add build hooks that can do whatever you want with the files. You could also just unpack the wheel, run python -m compileall on them, find -name "*.py" -delete and then repack. Plenty of options here that don't involve building eggs. The practice of running python setup.py has also been deprecated, and will probably be removed entirely at some point.

[agronholm]

One more thing: You did know that Python bytecode can be trivially decompiled back into readable source code by using tools like uncompyle6, right?