[Distutils] How to handle launcher script importability?

[Vinay Sajip]

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