Hey,
I just noticed that the new packaging macros create a .dist-info directory instead of .egg-info.
Just to be sure: There is no incompatibility between these two, right? So setuptools-based code can still retrieve all the package metadata in .dist-info directories? (If so I can just update the package in Fedora as that dist-info change itself does not break any backwards compatibility as far as other packages are concerned.)
Felix
On Nov 29, 2020, at 5:00 PM, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hey,
I just noticed that the new packaging macros create a .dist-info directory instead of .egg-info.
Just to be sure: There is no incompatibility between these two, right? So setuptools-based code can still retrieve all the package metadata in .dist-info directories? (If so I can just update the package in Fedora as that dist-info change itself does not break any backwards compatibility as far as other packages are concerned.)
Unless there’s something fedora specific going on, that should be correct. Upstream side, anytime pip installs from a Wheel it produces a dist-info instead of a egg-info, so if there was some compatibility issue, it should have been exposed awhile ago.
Am 29.11.20 um 23:11 schrieb Donald Stufft:
Unless there’s something fedora specific going on, that should be correct. Upstream side, anytime pip installs from a Wheel it produces a dist-info instead of a egg-info, so if there was some compatibility issue, it should have been exposed awhile ago.
Indeed, thank you.
Felix
On 11/29/20 11:11 PM, Donald Stufft wrote:
On Nov 29, 2020, at 5:00 PM, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hey,
I just noticed that the new packaging macros create a .dist-info directory instead of .egg-info.
Just to be sure: There is no incompatibility between these two, right? So setuptools-based code can still retrieve all the package metadata in .dist-info directories? (If so I can just update the package in Fedora as that dist-info change itself does not break any backwards compatibility as far as other packages are concerned.)
Unless there’s something fedora specific going on, that should be correct. Upstream side, anytime pip installs from a Wheel it produces a dist-info instead of a egg-info, so if there was some compatibility issue, it should have been exposed awhile ago.
Nothing Fedora specific going on... Well, except that we delete the RECORD file when installed via %pyproject_install.
Hence wrt backwards compatibility: pip might now refuse to uninstall the RPM installed package, while previously it would have done so happily. That is an improvement, but technically is not 100% backwards compatible behavior.
On 30.11.20 10:54, Miro Hrončok wrote:
Hence wrt backwards compatibility: pip might now refuse to uninstall the RPM installed package, while previously it would have done so happily. That is an improvement, but technically is not 100% backwards compatible behavior.
Oh, I can live with THAT :-)
Most of the bugs we are getting related to certbot is actually users messing around with pip manually (or adding incompatible third-party repos) so I'm all for users not breaking their system python install :-)
Felix
python-devel@lists.fedoraproject.org