[arch-dev-public] [RFC] Python 3.3.0 and PEP 394
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 ? 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. Any opinions ? Cheers, Stéphane [1] http://www.python.org/dev/peps/pep-0394/
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
On 13 September 2012 12:18, Allan McRae <allan@archlinux.org> 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? -- GPG/PGP ID: C0711BF1
On 13/09/12 20:32, Ray Rashif wrote:
On 13 September 2012 12:18, Allan McRae <allan@archlinux.org> 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
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. 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 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
Le 2012-09-13 08:04, Allan McRae a écrit :
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
On 13/09/12 21:53, Stéphane Gaudreault wrote: 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). 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.
On Thu, Sep 13, 2012 at 7:03 PM, Stéphane Gaudreault <stephane@archlinux.org> 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 14 September 2012 02:18, Sébastien Luttringer <seblu@seblu.net> 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. Andrea has since repackaged them as 'python2-pyqt' and simply 'pyqt', which looks, sounds and feels much better.
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
-- GPG/PGP ID: C0711BF1
On 13.09.2012 22:03, Rashif Ray Rahman wrote:
On 14 September 2012 02:18, Sébastien Luttringer <seblu@seblu.net> 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 Thu, Sep 13, 2012 at 10:27 PM, Florian Pritz <bluewind@xinu.at> wrote:
On 13.09.2012 22:03, Rashif Ray Rahman wrote:
On 14 September 2012 02:18, Sébastien Luttringer <seblu@seblu.net> 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:
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).
python2-qt python-qt
Those look absolutely nothing like 'PyQt', which is the project name.
$pkgbase would be pyqt (or even PyQt). IIRC, archweb already display split package by $pkgbase in "Recent Updates".
https://www.archlinux.org/packages/community/x86_64/linux-tools/ https://www.archlinux.org/packages/extra/x86_64/calligra/ Unfortunatly, packages doesn't have pkgbase information stored, so pacman is not able to find by $pkgbase. But we can use provides and groups to have a search working. By example, use group information, named by project name, which allow users which want use PyQt to search pacman -Ss pyqt and found python-qt and python2-qt. And users who (gracefully) writes "pacman -S pyqt" will be asked to choose which package to install.
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.
It's a compromise but squeezing the redundancy would be plus. Even change the package name, change it to something much more coherent. All of this works until there is no 2 different packages nammed PyQt4 and PythonQT. It's unlikely? Cheers, -- Sébastien "Seblu" Luttringer www.seblu.net
On 14 September 2012 05:26, Sébastien Luttringer <seblu@seblu.net> 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
On 14 September 2012 10:54, Rashif Ray Rahman <schiv@archlinux.org> 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.
-- 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, and reserve python2-something/python3-something when the "something" works only under version of Python specified in the name. Lukas
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 <schiv@archlinux.org> wrote: python2-something/python3-something when the "something" works only under version of Python specified in the name.
Lukas
On 14 September 2012 12:56, Stéphane Gaudreault <stephane@archlinux.org> wrote:
Is there any such package ? .py files could be compatible for both version, but .pyc and .pyo files are not.
Good point! But not all packages contains .pyc and .pyo, eg. python2-pyqt provides only .py files.
Xyne didn't appear to have write access so passing on his message as follows: ---------- Forwarded message ---------- From: Xyne <xyne@archlinux.ca> 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
On Fri, Sep 14, 2012 at 3:00 PM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
Xyne didn't appear to have write access so passing on his message as follows:
---------- Forwarded message ---------- From: Xyne <xyne@archlinux.ca> 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 it's not a matter of time. If python 4 is released with no major breaking with python 3, update will be smooth and we will never want to have a python4-foo and python3-foo like we don't want to have python3.2-foo and python3.3-foo. Another case, I talked with some python dev last week which explain me that python3 can be considered as a new language. They also suggest that /usr/bin/python should remains python2 and new program should use python3 in there sheebang (as mark of compatibily) Cheers, -- Sébastien "Seblu" Luttringer www.seblu.net
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
On 14/09/12 23:14, Alexander Rødseth wrote:
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-".
python2 is not being dropped.
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
On Thu, Sep 13, 2012 at 2:00 AM, Stéphane Gaudreault <stephane@archlinux.org> wrote:
Any opinions ?
I think this PEP give convention between distro and python developers to have portable scripts. Our part is to provide python2* and python3* symlinks. The dev parts is to use correct sheebang is there scripts (or better, let installer define it). The main message in this PEP to developper is DO_NOT_USE python it can refer to python 2.x or python 3.x. We can thanks this PEP to legitimate what archlinux is doing (promoting the future of python). Let user choose if his python is symlinked to python2 or python3 will not fix a day to day use of python2 and python3 scripts which doesn't respect this PEP and increase the current mess. About packages we fix by a sexy sed line, we can stay to our official /usr/bin/python interpreter as we do for each packages. -- Sébastien "Seblu" Luttringer www.seblu.net
participants (8)
-
Alexander Rødseth
-
Allan McRae
-
Florian Pritz
-
Lukas Jirkovsky
-
Rashif Ray Rahman
-
Ray Rashif
-
Stéphane Gaudreault
-
Sébastien Luttringer