On 5 April 2011 16:37, Dan McGee <dpmcgee@gmail.com> wrote:

I'm facing this exact situation with python-pip and python-virtualenv right now- both just became python 3 compatible, and as soon as I rename them I am going to break a lot of people's stuff. It would be fine if this all happened when we did the "great rebuild" as there would only be one time of breakage, but the situation right now is untenable- *every single time I see a python module being updated* I have to be scared as I can't tell whether the one being installed is 2 or 3, and whether I'm suddenly going to lose database connectivity or something.

Ah, had the same issue with my pygments package. But because only 3 packages depended on it, I just tweaked the dependencies in those. Now I'm thinking, couldn't we do: python-foo gets renamed to python2-foo and provides/conflicts/replaces=('python-foo') are introduced. python3-foo is added to the repo. The key detail here is the 'python3-' prefix, which allows us to replace python-foo with python2-foo. Looks like numpy [1] is using this approach. Another problem I noticed when I split pygments into Python 2 & 3 packages is command scripts that get installed to /usr/bin/; both versions use the same path, and will conflict. I chose to append a 2 to the command script installation path (/usr/bin/pygmentize -> /usr/bin/pygmentize2) in the Python 2 package. [1] http://projects.archlinux.org/svntogit/packages.git/tree/python-numpy/trunk/...