On 27 January 2018 at 13:46, Nathaniel Smith
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 | ncoghlan@gmail.com | Brisbane, Australia