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

[Daniel Holth]

On Thu, Jul 18, 2013 at 1:24 PM, 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?)

virtualenv /tmp/builder
/tmp/builder/bin/pip wheel -w /tmp/wheels -r requirements.txt

virtualenv /tmp/no-setuptools
/tmp/no-setuptools/bin/pip install --use-wheel
--find-links=/tmp/wheels --no-index -r requirements.txt

That is the anti-setuptools workflow I envision. The build environment
has an appropriate amount of setuptools and the no-setuptools
environment has none. This gives you the option of not having
setuptools if you don't want it, something that some people will
appreciate.

It does not try to avoid the non-problem of installing setuptools when
you actually need it.

Eventually there may be more sophisticated build requirements
handling, for whatever that's worth, so that you might not have to
have an explicit setuptools virtualenv. System packaging certainly
doesn't install build requirements into their own isolated
environment.