On 27 January 2018 at 13:46, Nathaniel Smith <n...@pobox.com> wrote: > The advantages are: > > - it's a simpler way to record information the information you want > here, without adding more special cases to dist-info: most code > doesn't even have to know what 'extras' are, just what packages are > > - it opens the door to lots of more advanced features, like > 'foo[test]' being a package that actually contains foo's tests, or > build variants like 'numpy[mkl]' being numpy built against the MKL > library, or maybe making it possible to track which version of numpy's > ABI different packages use. (The latter two cases need some kind of > provides: support, which is impossible right now because we don't want > to allow random-other-package to say 'provides-dist: cryptography'; > but, it would be okay if 'numpy[mkl]' said 'provides-dist: numpy', > because we know 'numpy[mkl]' and 'numpy' are maintained by the same > people.) > > I know there's a lot of precedent for this kind of clever use of > metadata-only packages in Debian (e.g. search for "metapackages"), and > I guess the RPM world probably has similar tricks. >
While I agree with this idea in principle, I'll note that RPM makes it relatively straightforward to have a single SRPM emit multiple RPMs, so defining a metapackage is just a few extra lines in a spec file. (I'm not sure how Debian's metapackages work, but I believe they're similarly simple on the publisher's side). We don't currently have a comparable mechanism to readily allow a single source project to expand to multiple package index entries that all share a common sdist, but include different subsets in their respective wheel files (defining one would definitely be possible, it's just a tricky migration problem to work out). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
