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

[Nick Coghlan]

On 19 July 2013 19:29, Paul Moore <p.f.moore at gmail.com> wrote:
> 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.

I was going to say it would affect Linux distro packagers (since the
multi-version support is necessary for us to hack together something
vaguely resembling parallel install support for Python libraries that
make backwards incompatible changes), but then I remembered that at
least Fedora & RHEL SRPMs generally call setup.py directly in the
build phase (with setuptools as a build dependency). This means that
what pip chooses when installing from source or a wheel won't actually
affect distro packaging (since I assume other distros are doing
something at least vaguely similar to what we do).

With our widely deployed (but still highly specialised) use case out
of the picture, I think you're probably right.

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

Right, I think the reasonable near term solutions are for pip to either:

1. generate zc.buildout style wrappers with absolute paths to avoid
the implied runtime dependency
2. interpret use of script entry points as an implied dependency on
setuptools and install it even if not otherwise requested

Either way, pip would need to do something about its *own* command
line script, which heavily favours option 1

Cheers,
Nick.

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