Nick Coghlan <ncoghlan <at> gmail.com> writes: > I previously thought distlib was going to be the repository for the > agreed, stable, "this is going to happen" stuff. It's OK that I was > wrong - I think you're right that somewhere is needed as an > experimental location to show some of the *possibilities* of the new > metadata, and to seed ideas for making it into the eventual standard > base that people can assume is readily available.
It's not just about completely new, experimental stuff. For example, the resources functionality isn't completely new territory. The PyPI interfacing is (IMO) a saner API than the one in distutils2. A better Windows story (for when launcher support when py.exe can't be used) is also not rocket science. > What that means though, is we need *something else* that indicates the > common core that people can assume will always be available. It's this If that "something else" you're thinking of is something that is supposed to live in the stdlib, then I see no reason why a subset of distlib couldn't be that something else, since stdlib changes are not on the table for 3.4. I certainly have never envisaged that distlib would be adopted wholesale into the stdlib (if at all) without peer review and any changes coming out of that. > common core which pip will need to factor out to remove their > dependency on setuptools, rather than adopting distlib wholesale, > experimental features and all. I honestly think you're making a bit too much of the "experimental" label here, even though it is a label that I use myself. For me, that label is most appropriate for the extended metadata that I collect from PyPI and which is the basis for distlib's smarter dependency resolution. If your concerns are about instability due to experimental features (and I quite understand the importance of stability in packaging), then there's nothing stopping anyone doing a technical review of distlib to see what any actual risks are. Indeed, I've invited such review from day one. > Currently, pip doesn't expose a programmatic API. I suggested to > Donald that it may make sense to start exposing one as "piplib". The I think this would be a mistake, and it seems a little early to make this sort of decision. You've given me to understand that pip could at some future point use (some subset of) distlib under the covers, with compatibility maintained at the CLI level. If that is still the case, then I don't see much value in having two lib layers. Like setuptools, pip has done sterling service, but it's not a codebase I'd like to see become the basis for our long-term packaging infrastructure. I don't mean to offend anybody by saying that - it's just software that has grown organically over time and IMO there will be technical debt to repay if we go down the route of exposing bits of it as Python APIs. It certainly feels like you're side-lining distlib, or planning to, whether or not that's the message you're intending to send. No matter :-) Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
