[Distutils] What does it mean for Python to "bundle pip"?

Nick Coghlan ncoghlan at gmail.com
Tue Aug 20 15:49:58 CEST 2013


On 20 Aug 2013 05:51, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 20 August 2013 11:25, Oscar Benjamin <oscar.j.benjamin at gmail.com>
wrote:
>>
>> On 20 August 2013 09:51, Paul Moore <p.f.moore at gmail.com> wrote:
>> > 1. Will the bundled pip go into the system site-packages or the user
>> > site-packages? Does this depend on whether the user selects "install
for all
>> > users" or "install for just me"?
>>
>> If you have get-pip then why not choose at that point whether you want
>> to install for the system or for all users e.g.: 'py -3.4 -m get-pip
>> --user' (or perhaps reverse the default)?
>
>
> That's not how get-pip is being proposed. It will run automatically on
installation of Python. If it were manually run, *and* if a --user flag was
included, then you would be correct.
>
>> > 2. If pip goes into system site-packages, what happens with the
uninstaller?
>> > It doesn't know about pip, so it won't uninstall Python cleanly. (Not a
>> > major point, you can delete the directory manually after uninstalling,
but
>> > it's untidy). Maybe the uninstaller should just unconditionally delete
all
>> > of site-packages as well as whatever files it knows were installed.
This is
>> > a "normal" issue when installing into the system Python, but for
people who
>> > avoid that and use virtualenvs (e.g. me :-)) it's new (and annoying, as
>> > we'll never use the system pip in any case...)
>>
>> Can you not just teach the Python installer to check for pip and
>> remove it if found?
>
>
> I'm not sure. That's my point, essentially. Who knows enough about the
Windows installer to do this correctly? If the answer is "nobody", then is
a best-efforts approach with some issues that we don't have anyone who
knows how to solve, an acceptable approach? Maybe it is, I'm not claiming
that this is a major issue, but we should note it in the PEP as a
limitation.
>
>> > This raises another point - to an extent, I don't care about any of
this, as
>> > I routinely use virtualenvs. But if using pip to manage the system
python is
>> > becoming the recommended approach, I'd like to understand what
precisely the
>> > recommendation is so that I can see if it's better than what I
currently do
>> > - for instance, I've never used --user so I don't know if it will be of
>> > benefit to me. I assume that this will go in the packaging user guide
in due
>> > course, but I don't know who will write it (does anyone have the
relevant
>> > experience? most people I know recommend virtualenv...)
>>
>> If I could install everything I wanted with pip then virtualenvs would
>> be more practical. Maybe when wheel distribution becomes commonplace
>> I'll start doing that. I basically always want to install a large
>> number of third party packages before I do anything though.
>>
>> So for me the procedure on ubuntu is something like:
>> 1) install ubuntu
>> 2) sudo apt-get install python-numpy python-scipy python-matplotlib
>> ipython python-sympy python-dev cython python-pygraph python-tables
>> python-wxgtk2.8 python-pywt python-sphinx ...
>>
>> On Windows the procedure is:
>> 1) Install Python
>> 2) Get MSIs for numpy, scipy, wxPython, matplotlib, PyQt, numexpr, ...
>> 3) Setup PATH or create a shell/batch script called 'python' that does
>> the right thing.
>> 4) Run ez_setup.py and Install pip
>> 5) Patch distutils (http://bugs.python.org/issue12641)
>> 6) Use pip for cython, sympy, ipython, pyreadline, spyder, sphinx,
>> docutils, line_profiler, coverage, ...
>> 7) Build and install my own commonly used private packages.
>> 8) Get more prebuilt binaries for other awkward packages when
>> necessary: pytables, numexpr, mayavi, ...
>>
>> (You can see why some people just install Python(x, y) or EPD right?)
>>
>> It takes quite a while to do all this and then I have basically all
>> the packages I want minus a few pippable ones. At this point I don't
>> really see the point in creating a virtualenv except to test something
>> that I'm personally developing. Or am I missing something?
>
>
> :-)
>
> Yes, it's a pain. My experience is better because I don't use that many
packages that need binaries. For those that I do, I maintain a local cache
of wheels that I convert from bdist_wininst installers using "wheel
convert" and then pip install works for everything. This is a really slick
experience, but it relies on me maintaining my local repo, and having an
appropriate -i flag added to pip (or I put it in pip.ini). As I work on
multiple PCs, it's still fiddly (I put the cache on my skydrive for ease).
>
> But yes, if I made extensive use of binary extensions, I'd hate this
approach. That's why I keep saying that the biggest win for wheels will be
when they become the common means of distributing Windows binaries on PyPI,
in place of wininst/msi.

Scientific users will always be better off with something like
hashdist/conda, since that ignores platform interoperability and easy
security updates in favour of hash based reproducibility. Continuum
Analytics also already take care of providing the prebuilt binary versions.

The pip ecosystem is more appropriate for pure Python code and relatively
simple C extensions (including cffi bindings).

Cheers,
Nick.

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


More information about the Distutils-SIG mailing list