[Proposal ] Name of Python's port
Hi, port search python shows me that every python2.5 port has prefix "py25" but that of 2.4 is only "py". If MacPorts would consider python2.4 is recommended python (due to some known problem) and called python2.4 port just "python", that would make sense, but ,unfortunately, it's not so. So IMHO using py24 prefix for 2.4 port would be more intuitive. What do you think of this? I' like to hear some comments on this and as a long-term goal, it would be nice to have a portnaming guildeline for python (or ALl ports across MacPorts project) Thanks in advance!
On Feb 1, 2008, at 23:45, js wrote:
port search python shows me that every python2.5 port has prefix "py25" but that of 2.4 is only "py". If MacPorts would consider python2.4 is recommended python (due to some known problem) and called python2.4 port just "python", that would make sense, but ,unfortunately, it's not so. So IMHO using py24 prefix for 2.4 port would be more intuitive.
What do you think of this? I' like to hear some comments on this and as a long-term goal, it would be nice to have a portnaming guildeline for python (or ALl ports across MacPorts project)
The guideline is: use a numbered prefix if there's a good reason to. A prefix was not used for the python 2.4 ports because there was no python 2.5 at the time. Now there is, and I think it was just deemed too much of a hassle to rename all the py-* ports to py24-*.
So, now that we have py25-* and even py30-* ports, let's do something about it. Renaming py-* t- py24-*. could be done in a simple perl regex like this $ find dports \! -path '*.svn*' -type f -print0 | xargs -0 perl -i -pe 's/py-/py24-/g' It might be better to leave py-* ports without any changes for a while to avoid confusion. Any comments? On Feb 3, 2008 8:41 AM, Ryan Schmidt <ryandesign@macports.org> wrote:
On Feb 1, 2008, at 23:45, js wrote:
port search python shows me that every python2.5 port has prefix "py25" but that of 2.4 is only "py". If MacPorts would consider python2.4 is recommended python (due to some known problem) and called python2.4 port just "python", that would make sense, but ,unfortunately, it's not so. So IMHO using py24 prefix for 2.4 port would be more intuitive.
What do you think of this? I' like to hear some comments on this and as a long-term goal, it would be nice to have a portnaming guildeline for python (or ALl ports across MacPorts project)
The guideline is: use a numbered prefix if there's a good reason to. A prefix was not used for the python 2.4 ports because there was no python 2.5 at the time. Now there is, and I think it was just deemed too much of a hassle to rename all the py-* ports to py24-*.
js> So IMHO using py24 prefix for 2.4 port would be more intuitive. js> What do you think of this? +1. In fact, with Python 2.6 and 3.0 on the way I suspect it would be best to add version numbers to all versions of Python for awhile. -- Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/ The major difference between Democrats and Republicans is that Republicans don't know that Randy Newman's lyrics are full of sarcasm.
Ryan Schmidt wrote:
What do you think of this? I' like to hear some comments on this and as a long-term goal, it would be nice to have a portnaming guildeline for python (or ALl ports across MacPorts project)
The guideline is: use a numbered prefix if there's a good reason to. A prefix was not used for the python 2.4 ports because there was no python 2.5 at the time. Now there is, and I think it was just deemed too much of a hassle to rename all the py-* ports to py24-*.
Fixing the current issues for the python25 port, or with MacPorts having /usr/bin/python as default, would be better than just renaming a lot of deprecated ports... For instance all ports using py-gtk2 was already forced to upgrade to using py25-gtk instead... ? --anders
On Feb 2, 2008, at 18:06, skip@pobox.com wrote:
js> So IMHO using py24 prefix for 2.4 port would be more intuitive.
js> What do you think of this?
+1. In fact, with Python 2.6 and 3.0 on the way I suspect it would be best to add version numbers to all versions of Python for awhile.
It has already been established that python 2.5 ports shall have the py25 prefix and python 3.0 ports shall have the py30 prefix. If there's a python 2.6 version coming, then these should use the py26 prefix. Python 2.4 ports use the py prefix because we had not established the rules at that time and it is a major hassle to change this now. There are a handful of ports that depend on python 2.3, but none of them are in the python category, so none of them have a py prefix. There are ports for python 2.2 and python 2.1 but I don't see any ports that depend on those.
Just as you said, it might not so easy to fix things all now, but I think changes for better are a good thing and worth the effort. Everyone love to see consistent system layout, right? And having a beautiful system forces the system to remain same, I think. On Feb 4, 2008 1:10 AM, Ryan Schmidt <ryandesign@macports.org> wrote:
On Feb 2, 2008, at 18:06, skip@pobox.com wrote:
js> So IMHO using py24 prefix for 2.4 port would be more intuitive.
js> What do you think of this?
+1. In fact, with Python 2.6 and 3.0 on the way I suspect it would be best to add version numbers to all versions of Python for awhile.
It has already been established that python 2.5 ports shall have the py25 prefix and python 3.0 ports shall have the py30 prefix. If there's a python 2.6 version coming, then these should use the py26 prefix. Python 2.4 ports use the py prefix because we had not established the rules at that time and it is a major hassle to change this now. There are a handful of ports that depend on python 2.3, but none of them are in the python category, so none of them have a py prefix. There are ports for python 2.2 and python 2.1 but I don't see any ports that depend on those.
Citando js :
Just as you said, it might not so easy to fix things all now, but I think changes for better are a good thing and worth the effort. Everyone love to see consistent system layout, right? And having a beautiful system forces the system to remain same, I think.
As python2.5 should be the stable version and python2.4 slowly disappear, I feel renaming dozens of ports is just not worth it. The future is bright but there is no python<2.5 in it. And in fact, obtaining a beautiful python modules tree would mean having one port per package that builds conveniently for each installed python, not having py24-blabla, py25-blabla, py26-blabla and py30-blabla that are identical but a few characters...
On Feb 4, 2008 1:10 AM, Ryan Schmidt <ryandesign@macports.org> wrote:
On Feb 2, 2008, at 18:06, skip@pobox.com wrote:
js> So IMHO using py24 prefix for 2.4 port would be more intuitive.
js> What do you think of this?
+1. In fact, with Python 2.6 and 3.0 on the way I suspect it would be best to add version numbers to all versions of Python for awhile.
It has already been established that python 2.5 ports shall have the py25 prefix and python 3.0 ports shall have the py30 prefix. If there's a python 2.6 version coming, then these should use the py26 prefix. Python 2.4 ports use the py prefix because we had not established the rules at that time and it is a major hassle to change this now. There are a handful of ports that depend on python 2.3, but none of them are in the python category, so none of them have a py prefix. There are ports for python 2.2 and python 2.1 but I don't see any ports that depend on those.
macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
On Feb 4, 2008, at 12:07, Emmanuel Hainry wrote:
Citando js :
Just as you said, it might not so easy to fix things all now, but I think changes for better are a good thing and worth the effort. Everyone love to see consistent system layout, right? And having a beautiful system forces the system to remain same, I think.
As python2.5 should be the stable version and python2.4 slowly disappear, I feel renaming dozens of ports is just not worth it.
Not dozens: 336.
The future is bright but there is no python<2.5 in it. And in fact, obtaining a beautiful python modules tree would mean having one port per package that builds conveniently for each installed python, not having py24-blabla, py25-blabla, py26-blabla and py30-blabla that are identical but a few characters...
This was debated before and it was decided by those who understand python that separate ports made more sense. I believe part of the reason was that you might want to have both python-24- and python-25- versions of a given port installed.
Emmanuel> As python2.5 should be the stable version and python2.4 slowly Emmanuel> disappear, I feel renaming dozens of ports is just not worth Emmanuel> it. Here's the current situation: % port search py- | egrep '^py' | egrep -vi 'no match' | wc -l 336 % port search py25- | egrep '^py' | egrep -vi 'no match' | wc -l 105 % port search py30- | egrep '^py' | egrep -vi 'no match' | wc -l 10 A little work with the comm(1) command suggests that 74 ports are common to the py- and py25- collections, 262 are unique to py-, and 31 are unique to py25-. How long do you think it will be before the py25-* ports significantly outnumber the py-* ports? It looks like that day is aways off to me, given that there are currently about eight times as many ports which appear to be specific to the Python 2.4 install as to the Python 2.5 install. -- Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/
Let me summarize this discussion. I proposed that MacPorts should use py24- prefix instead of py- for all Python 2.4 ports because - The python other than 2.4 uses this naming convention. - py- for 2.4 is not intuitive Suggested migration plan: - Copy existing py-* ports to py24-* and leave all py-ports as it for a while - Rename all py24-ports to to requires py24-* ports - Add warnings to py-* ports's post-install, saying "This is obsolete. Please use py24-* insetad" - Update py24-* ports only, make py-*'s obsolete This request, however, was rejected for the following reasons - There're already a mass amount of py-* ports in the source tree. (336 or more) - A mass renaming of ports would cause massive failures during upgrades - Python2.4 is old (2.5 is current stable) so the work is not worth the effort. Actually, I still believe this fix is worth the effort. I think that as long as py-* ports exists, users will possibly make a mistake, but I'll gave up the idea because no one think that's good thing to do... In any event, thanks for every comments you gave me.
I've seen this issue brought up a few times while I've been lurking on the list, and this naming convention has always confused me a bit and caused a fair amount of irritation (especially when I had 2.5 installed, and some other app went in and compiled and installed 2.4 for me.) So, my question is this, and my apologies if it's already been answered. Why does macports even have this problem? I can absolutely understand wanting to have multiple versions of python on the system. That's not what I'm contesting. But the other packages? It just doesn't make sense to me to duplicate that work. Why can't this be handled with varients? In many cases, it might be something as simple as to symlink the package files from one of the lib directories to the other. Even in more complicated setups, where there might additional work required, I don't understand why variants aren't used for this. On Feb 4, 2008, at 10:58 AM, skip@pobox.com wrote:
Emmanuel> As python2.5 should be the stable version and python2.4 slowly Emmanuel> disappear, I feel renaming dozens of ports is just not worth Emmanuel> it.
Here's the current situation:
% port search py- | egrep '^py' | egrep -vi 'no match' | wc -l 336 % port search py25- | egrep '^py' | egrep -vi 'no match' | wc -l 105 % port search py30- | egrep '^py' | egrep -vi 'no match' | wc -l 10
A little work with the comm(1) command suggests that 74 ports are common to the py- and py25- collections, 262 are unique to py-, and 31 are unique to py25-. How long do you think it will be before the py25-* ports significantly outnumber the py-* ports? It looks like that day is aways off to me, given that there are currently about eight times as many ports which appear to be specific to the Python 2.4 install as to the Python 2.5 install.
-- Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Robert M. Zigweid wrote:
I can absolutely understand wanting to have multiple versions of python on the system. That's not what I'm contesting. But the other packages? It just doesn't make sense to me to duplicate that work. Why can't this be handled with varients? In many cases, it might be something as simple as to symlink the package files from one of the lib directories to the other. Even in more complicated setups, where there might additional work required, I don't understand why variants aren't used for this.
Python libraries and extensions aren't binary compatible with mulitple versions of Python. So, symlinking something from Python 2.4 to Python 2.5 won't work if it's a binary extension--it would need to be recompiled. -- Kevin Walzer Code by Kevin http://www.codebykevin.com
Obviously the decision has already been made, so I won't comment. But I will note what I find annoying as a result of the chosen naming protocol. I went to install fetchmail and it started to install python24 despite my having python25 installed. I am new to macports from the linux world (in Mandriva, the python naming scheme is simply python with different versions) so I am not sure if this annoyance/problem is a result of fetchmail not having its dependencies set to be either or if it's a problem of the chosen naming scheme. And since the macports python24 does not work in Leopard (bus errors), I don't even have the choice of letting it install python24. But regardless, I shouldn't have to anyways, as I have python25 installed. I've manually installed fetchmail (with python25) in the meantime, but this defeats the whole purpose of having a packaging system. -Suresh
I am new to macports from the linux world (in Mandriva, the python naming scheme is simply python with different versions) so I am not sure if this annoyance/problem is a result of fetchmail not having its dependencies set to be either or if it's a problem of the chosen naming scheme.
Interesting. I think fetchmail port should be modified to requires python 2.5. Report this to the maintaiiner as a bug.
And since the macports python24 does not work in Leopard (bus errors), I don't even have the choice of letting it install python24. But regardless, I shouldn't have to anyways, as I have python25 installed.
I've manually installed fetchmail (with python25) in the meantime, but this defeats the whole purpose of having a packaging system.
Please report this as a bug, too if this is not a known issue.
participants (8)
-
Anders F Björklund
-
Emmanuel Hainry
-
js
-
Kevin Walzer
-
Robert M. Zigweid
-
Ryan Schmidt
-
skip＠pobox.com
-
Suresh Pillai