`pip install --upgrade python` tries to install CPython-2.5 #583

zed opened this Issue Jun 21, 2012 · 21 comments


None yet
7 participants

zed commented Jun 21, 2012

pip should produce an intelligible error message if someone tries to install/upgrade python using pip. It might be useful for people familiar with RVM but new to pip/virtualenv. A link to something like pythonz would be nice.


pnasrat commented Jun 22, 2012

I'd probably argue we shouldn't have the entry on pypi at all.



pnasrat commented Jun 22, 2012

What version of pip/virtualenv?

pnasrat@pnasrat:issue583$ ./ve/bin/pip install --upgrade Python
Requirement already up-to-date: Python in /usr/lib/python2.7/lib-dynload
Cleaning up...
pnasrat@pnasrat:issue583$ ./ve/bin/pip --version
pip 1.1.post2 from /tmp/issue583/ve/lib/python2.7/site-packages (python 2.7)
pnasrat@pnasrat:issue583$ virtualenv --version

zed commented Jun 22, 2012

pip/virtualenv versions:

$ pip install python
Requirement already satisfied (use --upgrade to upgrade): python in ./.pythonz/pythons/CPython-2.7/lib/python2.7/lib-dynload
Cleaning up...

$ pip install --upgrade python
Downloading/unpacking python
  Using download cache from /home/z/.pip/download_cache/http%3A%2F%2Fwww.python.org%2Fftp%2Fpython%2F2.5%2FPython-2.5.tgz
  Running setup.py egg_info for package python

$ pip --version
pip 1.0.2 from /home/z/.virtualenvs/tmp/lib/python2.7/site-packages/pip-1.0.2-py2.7.egg (python 2.7)

$ virtualenv --version

With updated versions:

$ pip install python
Requirement already satisfied (use --upgrade to upgrade): python in ./.pythonz/pythons/CPython-2.7/lib/python2.7/lib-dynload
Cleaning up...

$ pip install --upgrade python
Requirement already up-to-date: python in ./.pythonz/pythons/CPython-2.7/lib/python2.7/lib-dynload
Cleaning up...

$ pip --version
pip 1.1 from /home/z/.virtualenvs/tmp-newve/lib/python2.7/site-packages/pip-1.1-py2.7.egg (python 2.7)

$ virtualenv --version

jezdez commented Jun 22, 2012

Huh, so in other words this seems to have been fixed?

zed commented Jun 22, 2012

Read past the title. The issue is pip should not pretend that it may install python if it can't. An appropriate error message would fix it.


jezdez commented Jun 23, 2012

I see, thanks for the pointer.


pnasrat commented Jul 5, 2012

I raised the issue with Guido, he was unaware of this pkg on pypi, I need to chase further.


xavfernandez commented Oct 7, 2015

I think this issue could be dropped, especially since with pip 8.0 won't follow rel="download" anymore.

This is an old issue, but I think it should be revived. I just had a Student in an intro class try to upgrade python itself with:

$ pip install --upgrade python

and they got:

Collecting python
  Could not find a version that satisfies the requirement python (from versions: )
No matching distribution found for python

And they were very confused -- then decided that the reason it didn't work was because pip wouldn't upgrade to a beta version (3.6b at this date) -- rather than pip won't upgrade python itself at all.

So if someone DOES try to update Python with pip -- it would be nice if they got a nice meaningful message.

Meanwhile, it would be nice to have a better error message here anyway: if pip could make the distinction between finding no package with that name, rather than no package with the version specified, people would have a better idea what was up.


dstufft commented Nov 6, 2016

Python isn't a special name as far as pip is (currently) concerned and it just looks at PyPI. I wonder if @warsaw (who is one of the owner's of that name) would be opposed to uploading a "release" of it to PyPI which is just a sdist whose setup.py prints out a helpful error message. Unless he mirrored every single Python release it wouldn't help people who are doing pip install Python==3.6 or so, but it should catch what is likely the common case.

I guess what I'm suggesting is that the name "python" SHOULD be a special name as far as pip is concerned. This would make it impossible for anyone to have a package called Python -- but I think that's a good thing -- do we WANT anyone to be able to use the "python" name for a package???

BTW, when I search PyPi, I don't see a "python" package -- though maybe I'm missing it in the depths of all the python-* packages...


dstufft commented Nov 6, 2016

It's at https://pypi.org/project/Python/.

I guess the main reason I'd be concerned with making it a special name is that people could be using it as a name outside of PyPI. Although perhaps we could make it a special name only for the error case?

@dstufft: Kinda funny this happened to come up right during the recent discussion on the distutils list :-):


TL;DR for everyone else -- a lot of discussion about how pip is specifically designed NOT to manage python itself.

It's at https://pypi.org/project/Python/.

hmm, looks like that hasn't been touched since 2007 and is at version 2.5 -- not sure what its point ever was. I know that PyPi is first come first serve, but you'd think for special cases like this we could delete a package :-)

(it looks like @barry is active on other projects on PyPi, so could be consulted)

the main reason I'd be concerned with making it a special name is that people could be using it as a name outside of PyPI.

sure, they COULD -- but WTF? -- anyway, this could still be for pip searching PyPi -- I presume pip wouldn't have to check anything if you did:

pip install ./

for a package that happened to be named "python"

and "import python" would still work in Python.

(it looks like @barry is active on other projects on PyPi, so could be consulted)

Oh, is that Barry Warsaw? then no problem talking to him.


dstufft commented Nov 6, 2016

Yea it's Barry Warsaw :)

OK -- so here's a concrete proposal:

  1. Declare that as far as PyPi is concerned, the name "python" can not be used as a package name.

(Secondarily, python as a package name could be disallowed by python itself, though that would be a decision for the python core devs, and I'm not sure there's a reason to do that anyway.)

  1. add code to pip that gives folks a helpful error message if they try to "pip install python" -- regardless of version or upgrade or anything. Something alone the lines of:

"pip can not be used to install or upgrade the python interpreter itself. To Install or upgrade Python, please see the documentation of the source of your python installation"

Optionally, we could add more helpful text like:

"A python interpreter can be obtained from its original source, such as python.org, pypy.org, ironpython.net, jython.net, etc. It can also be obtained and managed by the operating system package manager, such as apt, yum or homebrew, or from third-party distributions such as Anaconda, Enthought, or Activestate."

Though now that I see how long that incomplete list is, maybe it's better to keep it short and sweet.

If this was done there would be no need to remove Barry's "python" package on PyPi -- it would simply not be installable, which it isn't anyway. Though I think it should be removed, I can't see what purpose it serves other than to confuse people.

Note: I see from:


that pip was started in 2008 -- AFTER the last update to the PyPi python package.

Granted, easy_install was around before that, but still.


xavfernandez commented Nov 7, 2016

I'm not a fan of adding a special cases for python.
Maybe the simplest solution would be to do something akin to https://pypi.python.org/simple/py.test/ which contains a simple sdist with the following code:

import sys
from distutils.core import setup

if __name__ == "__main__":
    if "sdist" not in sys.argv[1:]:
        raise ValueError("please use 'pytest' pypi package instead of 'py.test'")
        description="please use 'pytest' for installation",

and raise an appropriate message to the user for the python package ?

I"d rather the special case -- really "python" IS special :-)

but sure, such a package would solve much of the problem. Though it might require maintenance with new versions every time a new Python version comes out -- not a huge deal, but someone would have to do it.



pradyunsg commented Jun 16, 2017

Related: #4527

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment