Dan McGee | 5 Apr 15:37 2011
Picon

Re: [arch-dev] Packaging inconsistencies of python modules

Public list, no need to be private.

On Tue, Apr 5, 2011 at 6:54 AM, Ray Rashif <schivmeister@...> 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:
>
(Continue reading)

Evangelos Foutras | 5 Apr 16:18 2011
Picon

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

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.

(Continue reading)


Gmane