[Distutils] Q about best practices now (or near future)

[Paul Moore]

On 19 July 2013 05:23, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 19 July 2013 09:37, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> >> I think the point is that people might be dependent on this
> functionality and
> >
> >> changing it out from underneath them could break their world.
> >
> >
> > I got the point that Daniel made, and my question was about *how* their
> world would break, and whether we really need to support multiple versions
> of something installed side-by-side, with on-the-fly sys.path manipulation.
> If that is a real requirement which should be supported, shouldn't there be
> a PEP for it, if it's coming into Python? It's not supported by distutils,
> and it has been a point of contention.
>
> It's a real requirement - Linux distros need it to work around
> parallel installation of backwards incompatible libraries in the
> system Python. Yes, it's an implementation defined feature of
> pkg_resources (not setuptools per se), but it's one that works well
> enough even if the error message can be opaque and the configuration
> can get a little arcane :)
>

Just to be absolutely clear on my interest in this:

1. I believe (but cannot prove, so I'll accept others stating that I'm
wrong) that many people using setuptools for the console-script entry point
functionality, have no specific interest in or requirement for
multi-version. As an example, take pip itself. So while it is true that
functionality will be lost, I do not believe that users will actually be
affected in the majority of cases. That's not to say that just removing the
functionality without asking is valid.

2. Projects typically do not declare a runtime dependency on setuptools
just because they use script wrappers. Maybe they should, but they don't.
Again, pip is an example. So wheel-based installs of such projects can
break on systems without setuptools (pkg_resources). This is going to be a
bigger problem in future, as pip install from wheels does not need
setuptools to be installed on the target (and if we vendor setuptools in
pip, nor does install from sdist). Of course, after the first time you hit
this, you install setuptools and it's never a problem again. But it's a bad
user experience.

3. It's an issue for pip itself, as we explicitly do not want a dependency
on a system installed setuptools. So we have to hack or replace the
setuptools-generated wrappers.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130719/3c296650/attachment.html>