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

[Daniel Holth]

On Fri, Jul 19, 2013 at 5:29 AM, 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.
>
> 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.

pip should just add pkg_resources as a dependency for any package that
has console_scripts entry points.