Nick Coghlan <ncoghlan <at> gmail.com> writes:
Right. I wasn't really aware Vinay was adding experimental ideas to distlib, I thought it was just the proven stable core from distutils2, plus support for the draft PEPs, with the experimental stuff entirely in distil rather than in distlib.
I've been up front about what's in distlib all along - check the overview page in the distlib docs. Above all, I want the stuff I do to be *useful*, rather than tick boxes here and there. For example, there's no PEP covering distlib's functionality whereby dependency resolution happens *without* downloading/unpacking archives and running egg_info. We seem to take this sort of dependency resolution for granted in Linux distros, but for some reason Python packaging has to make do with a clunkier approach? Initially my work in this area was experimental, but it seems to work well (though some areas still need more work), and at some point I would expect to propose a PEP to cover it. However, lots of things are in flux and not in my direct control, so directing effort there now would likely involve rework when e.g. existing PEPs change, so it wouldn't be productive to do it yet.
If Vinay wants to do experimental extensions, they either need to happen somewhere other than distlib, or else we need a new library which is just the candidate for standard library inclusion with *nothing* that hasn't been discussed and agreed to through the PEP process.
Distlib aims to conform to the PEPs as they evolve, and anyone can raise an issue if they find non-conformance. In my view, one of the failures of distutils2 was that it did not include functionality that was actually useful to people and used by them, such as exports and package resources. I implemented exports in distlib before you added them to PEP 426, but that doesn't mean that I'm some kind of heretic for doing so. I've implemented package resources in distlib too, and there's no PEP yet covering it. You've specifically told me that you don't see distlib as a candidate for inclusion in Python in the 3.4 time frame, so what's the big hurry with getting the pitchforks out now?
As I said, I *thought* distlib was that library, but it appears Vinay doesn't currently see it that way :(
Nick, you haven't discussed this with me at all, and I don't see how you can come up with that interpretation from anything I've said in my posts here (or anywhere else). As I see it, you've explicitly told me that there's a very long time to go before distlib is even considered as a possible candidate for standardisation, and I can't see any valid reason why I can't keep adding useful features to it for now, because the experience gained from using them will inform any future PEPs relating to those features. When the time to consider standardisation is nearer, decisions can be made about what might need to come out and what can stay in, etc. and PEPs written to propose any things that aren't already covered. I've written distlib in a modular fashion and I don't expect such a process to be painful, and I would certainly expect to produce PEPs where needed.
Right. distlib can be a candidate for stdlib inclusion, or it can be a vehicle for distributing experimental features not covered by any PEP, it can't be both at the same time.
How is it that you're ready to call time on it now, already, even though you've told me standardisation is not something to be even considered until Python 3.5? Of the two options quoted above, you had already decided that it can't be the former in the short to medium term, and now you're saying you don't want it to be the latter either? I'm confused. I'd certainly like to keep making distlib and distil more useful. Regards, Vinay Sajip