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

[Paul Moore]

On 18 July 2013 18:24, Marcus Smith <qwcode at gmail.com> wrote:

>
> I think it's still useful to have pip vendor just pkg_resources (as
>> pip.pkg_resources). It's easy, it gives you enough to install wheels,
>> and it's not the only thing you would do.
>
>
> I agree.  there's 2 problems to be solved here
>
> 1) making pip a self-sufficient wheel installer  (which requires some
> internal pkg_resources equivalent)
> 2) removing the user headache of a setuptools build *dependency* for
> practically all current pypi distributions
>
> for #2, we have a few paths I think
>
> 1) bundle setuptools  (and have pip install "pkg_resources" for console
> scripts, if it existed as a separate project)
> 2) bundle setuptools (and rewrite the console script wrapper logic to not
> need pkg_resources?)
> 3) dynamic install of setuptools from wheel when pip needs to instal
> sdists (which is 99.9% of the time, so this feels a bit silly)
> 4) just be happy that the pip bootstrap/bundle efforts will alleviate the
> pain in new versions of python (by pre-installing setuptools?)
>

As you say, for #1 using an internal pkg_resources (probably distlib's, why
bother vendoring a second one?) works.

Given that pip forces use of setuptools for *all* sdist builds, I think we
have to bundle it for that purpose. I really dislike the need to do this,
but I don't see a way round it. And if we do, we can just as easily use the
real pkg_resources as distlib's emulation.

As regards console scripts, I think they should be rewritten to remove the
dependency on pkg_resources. That should be a setuptools fix, maybe
triggered by a flag (possibly implied by
--single-version-externally-managed, as the pkg_resources complexity is
only needed when multi-versions are involved). If Jason's not comfortable
with the change, then we'll probably have to find some way of doing it
within pip, which will likely to be a fairly gross hack (unless we go
really bleeding-edge and don't pit scripts into a wheel *at all* (or just
omit exes and -script.py files, I don't know) and put the exports metadata
in the wheel assuming that it's the wheel installer's job to create the
wrappers. We can do that for pip install, and we just have to assume that
other tools (wheel install, distlib) will do the same.

TBH, my preference is for the metadata approach, do it correctly from the
start.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130718/66f091cd/attachment-0001.html>