This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.araujo
Recipients dstufft, eric.araujo, ncoghlan, rbricheno
Date 2018-05-15.19:14:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526411677.37.0.682650639539.issue33388@psf.upfronthosting.co.za>
In-reply-to
Content
In the early days, I think distutils was updated to support new metadata PEPs, and then it stopped.  Now we have an ecosystem of tools that know how to work with metadata files created by distutils or setuptools; I worry that changing distutils could break them.

See https://bugs.python.org/issue33069#msg313826 and github discussions linked from that ticket for a change proposed recently.

The situation seems different here: new params could be added to setup and Distribution, and written only if present (with the right metadata version).  But I still worry that implicitly switching the metadata version could cause trouble.

Some years ago I thought it would be good to add things to distutils (new commands or options that don’t change existing code with all its quirks), like wheel generation or stable ABI tag support.  One could imagine for example a new metadata_version param to setup to have explicit opt-in to newer metadata format.  But this would require changes to the Metadata class, could have unexpected bugs, would only be available in Python 3.8.

If we don’t touch distutils, users can be directed to setuptools that is actively maintained, or other tools like flit that don’t have all the baggage.  It’s not a seamless experience yet, but things are getting better for packaging outside of the stdlib.
History
Date User Action Args
2018-05-15 19:14:37eric.araujosetrecipients: + eric.araujo, ncoghlan, dstufft, rbricheno
2018-05-15 19:14:37eric.araujosetmessageid: <1526411677.37.0.682650639539.issue33388@psf.upfronthosting.co.za>
2018-05-15 19:14:37eric.araujolinkissue33388 messages
2018-05-15 19:14:37eric.araujocreate