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

[Dan McGee]

Public list, no need to be private.

On Tue, Apr 5, 2011 at 6:54 AM, Ray Rashif <schivmeister at gmail.com> wrote:
> When I got ready to split python-scipy today (sorry angvp it appears
> to have taken me more than just "a day" to get to it), I realised I
> didn't know - or rather was confused about - how/what to name the
> python3 package. That is a direct result of not being confident about
> the naming scheme. If there ever has been any discussion with a
> conclusion, I'd like to be reminded of it. Otherwise..
>
> I remember very early on (during the python transition), the general
> consensus was:
>
> python2-foo (for any 2.x project or module)
> foo (for the more popular and bigger 3.x modules which are independent
> projects by their own like PyQt)
> python-foo (for the average 3.x module)
>
> So for eg. PyQt we would or were supposed to have (pardon me if I'm wrong):
>
> * python2-pyqt
> * pyqt
>
> And for NumPy:
>
> * python2-numpy
> * numpy
>
> Or failing that, at least:
>
> * python2-numpy
> * python-numpy
>
> However, PyQt is now:
>
> * python2-qt
> * python-qt
>
> A search for pyqt brings up only 'pyqt3' and 'eric'. I've added the
> term 'PyQt' to the desc to work around this in trunk.
>
> Moving on, NumPy is:
>
> * python2-numpy (which provides python-numpy..!?)
> * python3-numpy
>
> I'd like some clarification as to whether all these were intentional.
>
> If not, either way, I'd like to propose the topmost examples as a
> convention. I understand that it is tedious to go back and forth with
> the renaming and replacements, but if you all agree, I will help with
> as many of these packages as I can.

This is great, other than the fact that it totally screws up your
upgrade paths and it is all too easy to leave a system with the wrong
modules installed (3 vs 2). I wish I had spoken up sooner way back
when we did the migration but I wasn't thinking at all and this didn't
come to mind.

As Stéphane said, we have a problem here in those periods where a
package becomes python 3 compatible, is split, but all packages
depending on it are not rebuilt. Even this would not satisfy all our
issues as many packages optdepend on these modules, and/or are just
installed for someone's script X on their system that we aren't
tracking deps for in the first place. These two reasons make the
rename/rebuild idea not fully work, in my opinion.

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.

-Dan

P.S. Pacman doesn't help here at the moment-
https://bugs.archlinux.org/task/23410