pip installs SymPy 3.x on Python 2.7 and rc1 instead of the latest release #701

Closed
certik opened this Issue Oct 10, 2012 · 12 comments

Projects

None yet

4 participants

@certik
certik commented Oct 10, 2012

How to reproduce:

ondrej@hawk:/tmp$ virtualenv-2.7 xx 
New python executable in xx/bin/python 
cInstalling setuptools............done. 
Installing pip...............done. 
ondrej@hawk:/tmp$ source xx/bin/activate 
(xx)ondrej@hawk:/tmp$ pip install sympy 
Downloading/unpacking sympy 
  Downloading sympy-0.7.2.rc1.python3.tar.gz (5.3Mb): 5.3Mb downloaded 
  Running setup.py egg_info for package sympy 
    Traceback (most recent call last): 
      File "<string>", line 14, in <module> 
      File "/tmp/xx/build/sympy/setup.py", line 36, in <module> 
        import sympy 
      File "sympy/__init__.py", line 27, in <module> 
        raise ImportError("It appears 2to3 has been run on the codebase. Use " 
    ImportError: It appears 2to3 has been run on the codebase. Use 
Python 3 or get the original source code. 
    Complete output from command python setup.py egg_info: 
    Traceback (most recent call last): 

  File "<string>", line 14, in <module> 

  File "/tmp/xx/build/sympy/setup.py", line 36, in <module> 

    import sympy 

  File "sympy/__init__.py", line 27, in <module> 

    raise ImportError("It appears 2to3 has been run on the codebase. Use " 

ImportError: It appears 2to3 has been run on the codebase. Use Python 
3 or get the original source code. 

---------------------------------------- 
Command python setup.py egg_info failed with error code 1 in /tmp/xx/build/sympy 
Storing complete log in /home/ondrej/.pip/pip.log 

So first of all, it should not install the rc1 version, but the latest release. Second of all, it should not install the Python 3.x version when using Python 2.7.

More analysis by Aaron here:

https://groups.google.com/d/msg/sympy/JEwi4ohGB90/x0UEm2WIwlQJ

@asmeurer

I seriously doubt that pip will be not installing rc's any time soon, but is there a way that I can name the tarballs so that pip will install the Python 2 version in Python 2 and the Python 3 version in Python 3?

@qwcode
Contributor
qwcode commented Oct 15, 2012

the code mentioned above (and the subsequent code that uses it) seems to only handle restrictions based on major and micro version

so an uploaded sympy-0.7.2-py3.2.tgz would only be found/used by py3.2. I confirmed that.

given that, that would mean uploading dists for all the micro versions you want to support.

but I'm honestly not confident what the right/best answer is to this.

@qwcode
Contributor
qwcode commented Oct 15, 2012

for anyone else coming to this, this is in the context of what you mentioned on the list: "Due to our complicated (or at least non-trivial) 2to3 configuration, we have decided to ship separate tarballs for Python 2 and Python 3"

@asmeurer

Well, at least that would be a solution that would work. We will have to upload five versions, but it's doable.

@asmeurer

It would also have the advantage of us officially "unsupporting" 3.0 and 3.1. The disadvantage is that if 3.4 comes out, we will have to make sure to upload a tarball for it. But considering how hard pip tries to find the right tarball for the latest version, one would think it would try just as hard to guess what Python version it represents.

@asmeurer

It turns out it's not that easy, because PyPI won't let you upload two tarballs with the same md5 hash. So in addition to creating five different tarballs, I will have to modify each somehow to make their hashes different.

@asmeurer

Well, apparently multiple calls of setup.py sdist create tarballs with different md5 sums (probably a bug in and of itself, but whatever), so it's not too hard to do this. Users might be confused as to why there are apparently different downloads for Python 3.2 and 3.3 (I realized that there's no need to upload separate -py2.5, -py2.6, -py2.7 tarballs; a single sympy-0.7.2.tar.gz will be automatically used).

@jrioux
jrioux commented Oct 17, 2012

Without the "-py2.5" etc. naming scheme on the python 2 source, it's unreliable which version python3 pip install will pick up; it might as well try python 2 source. Look at other packages on pypi that supports python 2 and 3, and you'll see that other packages use the (admittedly quite annoying) naming scheme, so I doubt that the confusion among users lasts for too long.

@asmeurer

Well it seems that it does do the right thing as it is, so unless someone tells me otherwise, I'm just going to leave it.

@qwcode
Contributor
qwcode commented Feb 28, 2013

see #820 for pip only finding stable releases by default

as for pip responding to pypi metadata to limit downloads by version, as I said on catalog-sig, the long term solution is pep426 metadata that's exposed in pypi, but I guess I'm open to using trove short term, as an optional flag. just hesitant due to not thinking many people will use it? by maybe I'm off on that.

@qwcode qwcode closed this Feb 28, 2013
@asmeurer

It's also worth noting here that it matters what order you upload the files because pip uses the order on the PyPI simple page. I had to upload sympy-0.7.3-py3.3.tar.gz first and then sympy-0.7.3.tar.gz or else it would always grab sympy-0.7.3.tar.gz in Python 3.

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