[Distutils] How to handle launcher script importability?

[Nick Coghlan]

On 22 August 2013 08:12, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> 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.

Right, you didn't do anything wrong, I just wasn't really paying
attention because promoting distlib adoption has been firmly in the
"later" bucket for me, after the setuptools rehabilitation, pip
bootstrapping, etc. I can't fault you for not realising I believe
something I had never really written down anywhere :)

> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> 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.

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.

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
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'm actually OK with that, since it means we can aim for a
self-contained pip that serves as the basis for the rest of the
ecosystem, and is upgraded on the *pip* update cycle, rather than
CPython's. I'd been wondering how we'd avoid the "stale standard
library support" issue we ran into with distutils, and I think the pip
bootstrapping proposals give us the answer: we don't make the core
distribution infrastructure part of the standard library, we make it
part of *pip*. One of the key concepts of the bootstrapping idea is
that CPython maintenance releases will bundle newer versions of pip,
and also that pip will be able to upgrade itself in place, so if
people need newer distribution infrastructure "upgrade pip" is a much
lower risk proposition than "upgrade to a newer version of Python".

Currently, pip doesn't expose a programmatic API. I suggested to
Donald that it may make sense to start exposing one as "piplib". The
bootstrapping would then provide the pip CLI and the common utilities
in piplib, and that would be the more conservative core, leaving
distlib and distil free to push the boundaries with experimental
features that go beyond what the agreed standards currently support.
As ideas from distlib make their way into the relevant PEPs and hence
into piplib, then they will become available by default, but in the
meantime, people would be able to do a build dependency on distlib to
get the experimental features.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia