headers
Dan McGee | 5 Apr 2011 15:37
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)

Permalink | Reply |
headers
Evangelos Foutras | 5 Apr 2011 16:18
Picon
Gravatar

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)

Permalink | Reply |
headers
Ray Rashif | 5 Apr 2011 18:13

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

At first I didn't want to bring this up openly, as a precaution, but I
suppose it's alright.

On 5 April 2011 21:37, Dan McGee <dpmcgee@...> wrote:
> 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.

Yes, true. We're doing this now:

python-foo -> python2-foo:
  conflicts=('python-foo<$newver')

python-foo *new*:
  provides=('python3-foo')

python3-foo -> python-foo:
  provides=('python3-foo')
  conflicts=('python3-foo')
  replaces=('python3-foo')

If things depend on the old 'python-foo', we rebuild them. If things
like make/opt depends are missed, people file bug reports, and we
ammend as appropriate.

Two key points:
(Continue reading)

Permalink | Reply |
headers
Allan McRae | 6 Apr 2011 00:20
Gravatar

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

I think the correct approach is the one that has been started:

python2-foo  -> python-2.x package
python-foo  -> python-3.x package

I am against using python3-foo instead of python-foo...

We just need to bite the bullet and get this entirely fixed in our 
repos.  I did not encourage getting this done during the initial python 
change over as there was enough things to do, but I did not realise that 
it would becoming a mess now...  Do I hear a volunteer to start creating 
the TODO list?

While we are at it, we should make sure all python-3.x packages use the 
"#!/usr/bin/python3" or "#!/usr/bin/env python3" in their shebangs 
(similar to what we do for python-2.x packages).  That is the upstream 
recommended way of packaging.

Allan
Permalink | Reply |
headers
Jan de Groot | 6 Apr 2011 18:17

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

On Wed, 2011-04-06 at 08:20 +1000, Allan McRae wrote:
> I think the correct approach is the one that has been started:
> 
> python2-foo  -> python-2.x package
> python-foo  -> python-3.x package
> 
> I am against using python3-foo instead of python-foo...
> 
> We just need to bite the bullet and get this entirely fixed in our 
> repos. 

So naming scheme is more important than smooth upgrade paths? You can
fix everything in the repos, but you can't make a smooth upgrade path
without leaving lots of unused python3 libraries on systems where
python2-depending apps are installed.
With numpy, I chose the easy and smooth way, and that's the way of
adding provides and using python2 and python3 naming.

As a sidenote, I think it will be very funny to see python4 getting
released in the future. Then we'll have to rename all python packages to
python3-* and name the new ones python-* again.
Permalink | Reply |
headers
Allan McRae | 7 Apr 2011 13:19
Gravatar

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

On 07/04/11 02:17, Jan de Groot wrote:
> On Wed, 2011-04-06 at 08:20 +1000, Allan McRae wrote:
>> I think the correct approach is the one that has been started:
>>
>> python2-foo  ->  python-2.x package
>> python-foo  ->  python-3.x package
>>
>> I am against using python3-foo instead of python-foo...
>>
>> We just need to bite the bullet and get this entirely fixed in our
>> repos.
>
> So naming scheme is more important than smooth upgrade paths? You can
> fix everything in the repos, but you can't make a smooth upgrade path
> without leaving lots of unused python3 libraries on systems where
> python2-depending apps are installed.
> With numpy, I chose the easy and smooth way, and that's the way of
> adding provides and using python2 and python3 naming.

Consistent naming is more important to me.  That way it is easy to find 
the package you want.  At the moment "pacman -S python-numpy" installs a 
python2 version, which is inconsistent with (almost?) every other python 
module providing python-2.x and python-3.x versions.

If this is all done in one go, then we can do a news announcement ad 
advise that "pacman -Qqtd" will show the unnecessary packages.

> As a sidenote, I think it will be very funny to see python4 getting
> released in the future. Then we'll have to rename all python packages to
> python3-* and name the new ones python-* again.
(Continue reading)

Permalink | Reply |

Gmane