[arch-general] [arch-dev-public] [arch-dev] Packaging inconsistencies of python modules

[Evangelos Foutras]

On 5 April 2011 16:37, Dan McGee <dpmcgee at 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/PKGBUILD