On 13/09/12 20:32, Ray Rashif wrote:

On 13 September 2012 12:18, Allan McRae wrote:

...

On 13/09/12 10:00, Stéphane Gaudreault wrote:

...

Python 3.3.0 should be released around September 22. I would like to take this opportunity to implement some of the recommendations of the PEP 394 [1]. This PEP was mostly done in reaction to what Arch did to the /usr/bin/python symlink (in summary, most python devs are against the move to python3 as a default at this time).

In short: python2 should refer to some version of Python 2.x python3 should refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

This means that we should never have a reference to '#!/usr/bin/python' in any of our packages. All those reference should be changed to /usr/bin/python2 to refer to Python 2.x and /usr/bin/python3 for Python 3.x. The idea here is that a system without any python symlink should work without problem. Maybe namcap could be used to detect wrong shebang ?

This is necessary as far as I am concerned.

And you have also been mentioning this from as far back as I can remember since the move. Therefore I would assume this is not (going to be) a problem if we have been listening.

So now do we simply remove the python symlink and leave it up to the users?

No. We keep it as python -> python3. The user can change it to point it at python2 if they want but given we have no alternatives system in pacman, it will revert on python3 upgrades. Maybe something to implement... Allan

On 13/09/12 21:53, Stéphane Gaudreault wrote:

Le 2012-09-13 00:18, Allan McRae a écrit :

...

On 13/09/12 10:00, Stéphane Gaudreault wrote:

...

Python 3.3.0 should be released around September 22. I would like to take this opportunity to implement some of the recommendations of the PEP 394 [1]. This PEP was mostly done in reaction to what Arch did to the /usr/bin/python symlink (in summary, most python devs are against the move to python3 as a default at this time).

In short: python2 should refer to some version of Python 2.x python3 should refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

This means that we should never have a reference to '#!/usr/bin/python' in any of our packages. All those reference should be changed to /usr/bin/python2 to refer to Python 2.x and /usr/bin/python3 for Python 3.x. The idea here is that a system without any python symlink should work without problem. Maybe namcap could be used to detect wrong shebang ? This is necessary as far as I am concerned.

...

Another possibility, suggested by Allan, would be to go even further and use /usr/bin/python3.3 and /usr/bin/python2.7 for all shebangs. Then /usr/bin/python can point to any version and /usr/bin/python2 and /usr/bin/python3 can point to any pyhton2.x and python3.x respectively. These numbers in the shebangs will be changed when python bump is version number as we need to rebuild almost everything anyway. I'm leaning towards that being to much effort. Just using python2/python3 should be enough.

One thing not mentioned in this email is that we really need to sort out the package naming in the repos. Two options:

python-foo python2-foo

or

python3-foo python2-foo

I personally would go for the first option, under the assumption that python4 will not exist for many years.

Allan

I did not mentioned the packages name because I am fine with the statu quo on this.

What is the status quo? Something called python-foo can be either python2 or python3 at the moment.

If there is a concensus that we want to change the naming, I would suggest

- change the name of the python pkg -> python3

- Change the package names with the following structure: pkgbase = python-something pkgname = ('python2-something' 'python3-something')

- If a package only has python 2 or 3 version, it could follow a similar structure : pkgbase = python-something pkgname = ('python3-something') OR pkgname = ('python2-something')

Stéphane

On Thu, Sep 13, 2012 at 7:03 PM, Stéphane Gaudreault wrote:

Le 2012-09-13 08:04, Allan McRae a écrit :

...

On 13/09/12 21:53, Stéphane Gaudreault wrote:

...

Le 2012-09-13 00:18, Allan McRae a écrit :

...

On 13/09/12 10:00, Stéphane Gaudreault wrote:

...

Python 3.3.0 should be released around September 22. I would like to take this opportunity to implement some of the recommendations of the PEP 394 [1]. This PEP was mostly done in reaction to what Arch did to the /usr/bin/python symlink (in summary, most python devs are against the move to python3 as a default at this time).

In short: python2 should refer to some version of Python 2.x python3 should refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

This means that we should never have a reference to '#!/usr/bin/python' in any of our packages. All those reference should be changed to /usr/bin/python2 to refer to Python 2.x and /usr/bin/python3 for Python 3.x. The idea here is that a system without any python symlink should work without problem. Maybe namcap could be used to detect wrong shebang ?

This is necessary as far as I am concerned.

...

Another possibility, suggested by Allan, would be to go even further and use /usr/bin/python3.3 and /usr/bin/python2.7 for all shebangs. Then /usr/bin/python can point to any version and /usr/bin/python2 and /usr/bin/python3 can point to any pyhton2.x and python3.x respectively. These numbers in the shebangs will be changed when python bump is version number as we need to rebuild almost everything anyway.

I'm leaning towards that being to much effort. Just using python2/python3 should be enough.

One thing not mentioned in this email is that we really need to sort out the package naming in the repos. Two options:

python-foo python2-foo

or

python3-foo python2-foo

I personally would go for the first option, under the assumption that python4 will not exist for many years.

Allan

I did not mentioned the packages name because I am fine with the statu quo on this.

What is the status quo? Something called python-foo can be either python2 or python3 at the moment.

I mean that I don't really care if we use

python-foo python2-foo

or

python3-foo python2-foo

even if I have a preference for the latter (also used in many other distro).

We also have python libraries not prefixed by python- (e.g: pyalpm, pycups, pygtk, etc), I think we should also update with pkgbase=pygtk pkgname=(python-gtk python2-gtk)

However, it would be nice if we could have consistent maning across all the packages at the end of the python 3.3.0 rebuild.

I prefer the first, we have the same case with lua and we should let program name be the last upstream "stable" version. Python is python 3, python 2 is dying (hardly) and I hope move from python 3 to python 4 will be smooth. Cheers, -- Sébastien "Seblu" Luttringer www.seblu.net

On 13.09.2012 22:03, Rashif Ray Rahman wrote:

On 14 September 2012 02:18, Sébastien Luttringer wrote:

...

We also have python libraries not prefixed by python- (e.g: pyalpm, pycups, pygtk, etc), I think we should also update with pkgbase=pygtk pkgname=(python-gtk python2-gtk)

That breaks common knowledge and conventional project names. This happened with pyqt:

python2-qt python-qt

Those look absolutely nothing like 'PyQt', which is the project name. We worked around this for a while using 'PyQt:' in the description so that it'd come up in searches for 'pyqt'. You could also provide for it in both, but that would still be a workaround.

python2-pyqt python2-pygtk The little bit of redundancy (python-py) isn't too bad IMHO and it's a clear naming scheme without special cases. -- Florian Pritz

On 14 September 2012 05:26, Sébastien Luttringer wrote:

I'm not sure it's very important (and possible) to use the project name without alteration in our package name. As you said, the most important is to be able to find it (by a search) with a minimum common sense.

Developer which use pyqt, will search something like: $ pacman -Sqs pyqt4 eric eric4 and doesn't found it. Because they may use the real name of the python library (import PyQt4). ... SNIP ...

Good one, we must provide for that. Nevertheless, what I meant was _not_ to have: python-qt python2-qt python-gtk python2-gtk But to have: pyqt python2-pyqt pygtk python2-pygtk As we have now. Prepending 'python' everywhere is fine, as long as the 'pyX' name remains. Now the ideal scenario would be: John: Fetch me 'pyalpm' Pacman: Do you want python(3)-pyalpm or python2-pyalpm? Now that I look at it that way prepending 'python' would be better. -- GPG/PGP ID: C0711BF1

Le 2012-09-14 05:16, Lukas Jirkovsky a écrit :

...

Good one, we must provide for that. Nevertheless, what I meant was _not_ to have:

python-qt python2-qt python-gtk python2-gtk

But to have:

pyqt python2-pyqt pygtk python2-pygtk

As we have now. Prepending 'python' everywhere is fine, as long as the 'pyX' name remains. Now the ideal scenario would be:

John: Fetch me 'pyalpm' Pacman: Do you want python(3)-pyalpm or python2-pyalpm?

Now that I look at it that way prepending 'python' would be better.

-- GPG/PGP ID: C0711BF1 Just my 2 cents: I'd prefer "python-something" when the "something" is compatible with both Python 2 and Python 3, Is there any such package ? .py files could be compatible for both version, but .pyc and .pyo files are not. and reserve

On 14 September 2012 10:54, Rashif Ray Rahman wrote: python2-something/python3-something when the "something" works only under version of Python specified in the name.

Lukas

Xyne didn't appear to have write access so passing on his message as follows: ---------- Forwarded message ---------- From: Xyne Date: 14 September 2012 19:57 Subject: Re: [arch-dev-public] [RFC] Python 3.3.0 and PEP 394 Rashif Ray Rahman wrote:

Good one, we must provide for that. Nevertheless, what I meant was _not_ to have:

python-qt python2-qt python-gtk python2-gtk

But to have:

pyqt python2-pyqt pygtk python2-pygtk

As we have now. Prepending 'python' everywhere is fine, as long as the 'pyX' name remains. Now the ideal scenario would be:

John: Fetch me 'pyalpm' Pacman: Do you want python(3)-pyalpm or python2-pyalpm?

Now that I look at it that way prepending 'python' would be better.

I also think that prefixing "python" in all cases makes sense. The prefix indicates that it is a library/module in our naming scheme and omitting it even in the case of naming redundancy (e.g. python-py*) creates exceptions to an otherwise uniform rule. I also strongly support the idea of using python3-foo python2-foo even if Python 4 may be a long way off. It is a consistent naming scheme that is completely unambiguous and it will avoid considerable hassle when Python 4 is finally released. I think simple rules should be preferred and in the case of python libraries/modules the simplest one is this: python<version>-<project name> e.g. "python3-pyalpm" Both the version and project name are clear, and it is fully searchable with Pacman. When a user is looking for a Python package, the user is not looking for a given project but rather a specific implementation of that project that is compatible with their own project. The user doesn't just want "foo", the user wants an implementation of "foo" in e.g. Python 3. It does indeed make sense to ask the user which version he wants (python2-foo or python3-foo?). The last argument that I have for always including the version number in the "python" prefix is that Python 2 and Python 3 are effectively different languages. There should be a unique prefix associated with each language for consistent naming, and that prefix should be permanent to avoid compatibility issues in the future. "python3-" clearly indicates that the package is for the Python 3 language. "python-" is a much more nebulous term that simply indicates that the package is for some version of Python that depends on when the package was created. The KISS approach here comes at the cost of a single character ('3') in some package names. Given all the hassle that it saves, I think it is clearly worth a few hundred bytes. Regards, Xyne ---------- Forwarded message ---------- -- GPG/PGP ID: C0711BF1

Would it be feasible to install the needed files for both python2 and python3? If John said "Fetch me 'pyalpm'", could he not get a few files installed in both /usr/lib/python2.7/ and /usr/lib/python3.2/? The disk usage is negligible and having both installed would be unproblematic (or at least be likely to solve more problems than it creates). There are other examples of packages including more files than strictly requested, like header files in lib* packages and additional documentation and examples for some packages. If this feels to un-Arch-like, a "clean cut" alternative would be to drop python2 completely and move everything that has to do with python2 to AUR, only keeping python3 and just prepend all python package names with "python-". Just my two cents, please don't flame me. -- Best regards, Alexander Rødseth, TU

Le 2012-09-14 09:19, Allan McRae a écrit :

...

If this feels to un-Arch-like, a "clean cut" alternative would be to drop python2 completely and move everything that has to do with python2 to AUR, only keeping python3 and just prepend all python package names with "python-".

On 14/09/12 23:14, Alexander Rødseth wrote: python2 is not being dropped.

I think it is good a good practice to try to move as much as possible to python 3, but python 2 will remain supported for some years. As a point of reference, upstream will provide maintenance releases for python 2 until at least 2015. Stéphane