#13
- Created on2010-03-11 15:31
- Reported by
- StatusFixed
- PriorityHigh (2)
- Assigned to
- Plan Level-
- Due Date-
SQLPython 1.7.1 requiring 3.x urllib due to cmd2
I installed sqlpython 1.7.1 from PyPI using pip into a clean virtualenv on Ubuntu 9.10 (karmic) and it tracebacked at:
urllib.request is a python 3.x library which is a refactoring of python 2.x's urllib2.
The version of cmd2 that was installed (automatically, due to dependency definition) is 0.6.1. A full listing of modules that I have installed is:
The python version is:
File "/home/wam/projs/virtualenvs/ips_dashboard/lib/python2.6/site-packages/cmd2.py", line 36, in <module>
import urllib.request, urllib.parse, urllib.errorurllib.request is a python 3.x library which is a refactoring of python 2.x's urllib2.
The version of cmd2 that was installed (automatically, due to dependency definition) is 0.6.1. A full listing of modules that I have installed is:
$ pip freeze
Genshi==0.5.1
cmd2==0.6.1
gerald==0.3.6
pyparsing==1.5.2
sqlpython==1.7.1
wsgiref==0.1.2The python version is:
$ python Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2
Leave a comment
on 2010-03-11 15:34 *
By William McVey
One other comment, I notice that there are several eggs on PyPI for cmd2. My site packages contains the following:
So it does look like pip pulled the proper egg for this platform.
cmd2-0.6.1-py2.6.egg-info gerald pyparsing_py3.pyc cmd2.py gerald-0.3.6-py2.6.egg-info pyparsing.pyc cmd2.pyc pip-0.6.1-py2.6.egg setuptools-0.6c11-py2.6.egg easy-install.pth pyparsing-1.5.2-py2.6.egg-info setuptools.pth genshi pyparsing.py sqlpython Genshi-0.5.1-py2.6.egg-info pyparsing_py3.py sqlpython-1.7.1-py2.6.egg-info
So it does look like pip pulled the proper egg for this platform.
I did some more debugging on this and it looks more like a packaging issue in cmd2. First, it's important to realize that pip has a strong aversion to binary eggs (as do I) as a package exchange format, so it will tend to prefer to download source tarballs and install them (into .egg directories). For cmd2, there are two source tarballs listed, and the first one is specifically for python 3, but is not labelled as such. pip sees the source tarball that matches the version and platform requirements and uses it:
This can be seen via:
The stats at http://pypi.python.org/pypi/cmd2 would imply that other people are having the same problem (cmd2's python3 tar ball is 3 times more downloaded than the version 2 one, and if I were to bet on why, I'd say it's because of the ordering of the tarballs and not the popularity/prevalence of python3 installations). My best suggestion would be to try and attach a python version onto the source distribution that is specifically for the python 3 release.
I installed cmd2 via a manual download of the python2.x tarball and sqlpython ran without a problem. As this is more a cmd2 issue rather than a sqlpython issue, I'm going to reassign ownership to Catherine (ordinarily, I'd just open up a new ticket in the cmd2 tracker, but non-privileged users apparently don't have new-ticket permission in that tracker, so I'll just leave this one open, sorry).
This can be seen via:
$ pip install -U cmd2 Downloading/unpacking cmd2 Downloading cmd2-0.6.1.py3.tar.gz (52Kb): 52Kb downloaded Running setup.py egg_info for package cmd2
The stats at http://pypi.python.org/pypi/cmd2 would imply that other people are having the same problem (cmd2's python3 tar ball is 3 times more downloaded than the version 2 one, and if I were to bet on why, I'd say it's because of the ordering of the tarballs and not the popularity/prevalence of python3 installations). My best suggestion would be to try and attach a python version onto the source distribution that is specifically for the python 3 release.
I installed cmd2 via a manual download of the python2.x tarball and sqlpython ran without a problem. As this is more a cmd2 issue rather than a sqlpython issue, I'm going to reassign ownership to Catherine (ordinarily, I'd just open up a new ticket in the cmd2 tracker, but non-privileged users apparently don't have new-ticket permission in that tracker, so I'll just leave this one open, sorry).
Hmm... I guess this particular effort to use PyPI to make both Py2 and Py3 code available is a failure. I don't know any way to signal to pip that it should use the standard-named tarball instead of the nonstandard-named one.
The only resolution I can think of at the moment is to delete the py3 tarball and instruct users to run 2to3 by hand on the tarball if they want to run under Python3. I look forward to a better solution.
The only resolution I can think of at the moment is to delete the py3 tarball and instruct users to run 2to3 by hand on the tarball if they want to run under Python3. I look forward to a better solution.
on 2010-03-13 05:54 *
By William McVey
Check out http://packages.python.org/distribute/python3.html for one way to allow Python3 users to download your (single) source package and install an installation suitable for their python interpreter. A good example of a package that uses this technique is Jinja2.
Alternatively, you could build a python3 hierarchy under your source tar ball (perhaps as part of a package release process (it wouldn't have to be checked into revision control if you didn't want it to be) and then let setup.py pick which source hierarchy to install into the cmd2 module at runtime based on sys.version_info. A good example of this technique is demonstrated in the setup.py of http://pypi.python.org/pypi/bsddb3/
Alternatively, you could build a python3 hierarchy under your source tar ball (perhaps as part of a package release process (it wouldn't have to be checked into revision control if you didn't want it to be) and then let setup.py pick which source hierarchy to install into the cmd2 module at runtime based on sys.version_info. A good example of this technique is demonstrated in the setup.py of http://pypi.python.org/pypi/bsddb3/