python 3 problem with cmd2

[Pavol Lisy]

I had problem to run sqlpython because it seems cmd2 on Pypi is in
python 3 version (import urllib.request in cmd2.py -> give error in
python 2.6 (ubuntu karmic) )

sudo pip install -U cmd2
Downloading/unpacking cmd2
Downloading cmd2-0.6.1.py3.tar.gz

My workaround then ->

sudo pip uninstall cmd2
sudo easy_install
http://pypi.python.org/packages/2.6/c/cmd2/cmd2-0.6.1-py2.6.egg
-----

warning:
sudo pip install -U sqlpython # "upgrade" cmd2 to python3 version again!!!

[Catherine Devlin]

Hi, Pavol.  Um, hmm - I see - I uploaded source tarballs for py2 and py3 versions of cmd2 ... and it seems pip chose to try to install from the py3 version.

Does anybody know, when PyPI contains two different source tarballs, how pip decides which one to use?  Is there any way we can control it?

The eggs work fine, indeed, but pip doesn't use eggs.

Thanks!

--
You received this message because you are subscribed to the Google Groups "sqlpython" group.
To post to this group, send email to sqlp...@googlegroups.com.
To unsubscribe from this group, send email to sqlpython+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sqlpython?hl=en.

--
- Catherine
http://catherinedevlin.blogspot.com/
*** PyCon * Feb 17-25, 2010 * Atlanta, GA * us.pycon.org ***

[wam]

Funny, I ran into this yesterday and filed a ticket for the issue at
https://www.assembla.com/spaces/sqlpython/tickets/13-sqlpython-1-7-1-requiring-3-x-urllib-due-to-cmd2
before joining this group.

On Mar 4, 1:42 pm, Catherine Devlin <catherine.dev...@gmail.com>
wrote:

> Does anybody know, when PyPI contains two different source tarballs, how pip
> decides which one to use?  Is there any way we can control it?

Well, pip goes through the pages, collecting links to potential
downloads and throwing out links for versions of the software that
don't match. The possible candidates are added to a list and in the
absence of version info, the first one found is the install candidate.
In pip 0.6.3, this behavior is all defined in pip.index.PackageFinder

Most packages I've seen follow one of the following approaches:

1) One unified code base with conditional code to allow same source
to
install and run in either environment (e.g. coverage)
2) Split code base but unified source distribution, and setup.py
tricks to
conditionally install different modules within the source
distribution
depending on python version (e.g. bsddb3)
3) Distribute python 2.x code and run 2to3 (and other source hacks)
on
install (e.g. Jinja2)
4) Split projects names with their own source packages and separate
project
pages in PyPI (e.g. jsonlib-python3 & jsonlib)

I've never seen two separate source distributions for the same version
of code attached to the same single project until cmd2. Of course,
just cause I haven't *seen* it doesn't mean it doesn't happen.

-- William