[Catalog-sig] Flag to tell pip to only install uploaded files

[Aaron Meurer]

On Jun 22, 2012, at 6:58 PM, PJ Eby <pje at telecommunity.com> wrote:

On Fri, Jun 22, 2012 at 8:21 PM, Aaron Meurer <asmeurer at gmail.com> wrote:

> Hi.
>
> I'm following up on a discussion on the pip mailing list
> (
> https://groups.google.com/forum/#!topic/python-virtualenv/PZNj9pC6aKA/discussion
> ),
> where I was directed here.
>
> Would it be possible to add some kind of a flag to PyPI that would let
> package maintainers tell pip to install only the uploaded file (or
> possibly also the file given by a direct link), and no others?
>
> Currently, pip aggressively tries to find the latest version of a
> package by crawling all links on the PyPI page, even those from older
> versions.  This is a headache to me as a package maintainer because it
> means that pip is quite often installing the wrong thing. Recently,
> pip was trying to install our html docs because we had a file uploaded
> at Google Code named "sympy-0.7.1-html-docs",


The simple way to correct this problem is to rename the file
'sympy-html-docs-0.7.1' - this will fix things for all installers that
follow easy_install's discovery protocol, including pip and zc.buildout.


Yes, I did this. But it doesn't solve the issue of installing our release
candidates, or trying to install who knows what because of the discovery
"protocol" (which I would call the discovery magic).



> which it deemed to be a
> newer version than "sympy-0.7.1".  There's also the issue that every
> time we put out a release candidate for a new version, pip starts
> installing that, when I would prefer it to only install stable final
> releases.  It's also, as I noted on the other discussion list, a bit
> of a security risk.
>

zc.buildout includes a flag to prefer stable releases, and I believe some
other installation tools do as well.  You might suggest they add such a
flag to pip and move towards using it by default.


The pip guys don't want to make this change, I guess because of the
problems it would cause with who knows how many packages wouldn't be
following this. See the discussion I linked to. I do agree that this would
be the better way to do it (but I can think of about a thousand "better
ways to do it" as far as Python packaging is concerned, but none of them
will happen, or at least not within the timeline that I'm hoping for).

Aaron Meurer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120622/3fc9bdc5/attachment.html>