Le 07-02-17 à 11:18, source_changes@macosforge.org a écrit :
Revision 22092 Author mww@macports.org Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007) Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ? yves
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org a écrit :
Revision 22092 Author mww@macports.org Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007) Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25- * ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ? yves
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
Revision 22092 <http://trac.macosforge.org/projects/macports/changeset/22092> Author mww@macports.org <mailto:mww@macports.org> Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007)
Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :) Regards, Blair
On 17.02.2007, at 17:42, Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org a écrit :
Revision 22092 Author mww@macports.org Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007) Log Messagenew port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py- * ports for python packages that don't use a PortGroup ?
No, I'd rather say we leave the py- prefix for 2.4 and use py25- for python 2.5; We could rename all py- ports to py24- but that'll probably more of a headache than just leaving them like this. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
Revision 22092 <http://trac.macosforge.org/projects/macports/ changeset/22092> Author mww@macports.org <mailto:mww@macports.org> Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007)
Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py- * ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question. I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration. But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ? yves
On 18.02.2007, at 17:47, Yves de Champlain wrote:
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
Revision 22092 <http://trac.macosforge.org/projects/macports/ changeset/22092> Author mww@macports.org <mailto:mww@macports.org> Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007)
Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question.
I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration.
But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ?
Depends: If the port just needs "some" python interpreter at run time, you don't need a py- named port at all, so are just for python modules. For python modules the problem is, that they install themselves in $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or taken 2.3 into account: three) directories, or at least I wouldn't try to - there is code that works with 2.4 but not 2.5 and vice versa, so we'll run into problems here, sooner or later. Currently our "main" python is v2.4 and I'd say we'd stay with that at least until 2.5.1 is out. But even then there is software that only will work with 2.4, so please don't move py- (2.4) ports to py25- (2.5) ones. If you need a python 2.5 version of that module, duplicate the port. Duplicates are fine here, as I'd expect that some modules will switch to 2.5 compatible code so we will probably have something like this in the future: py-module, version 1.8 py25-module, version 2.2 So we should approach this "switch" slowly, duplicating all the modules we need for 2.5 - if they work. In some years we probably can then nuke the py- (2.4) modules when the py41 ports take over... ;) cheers, -Markus -- Markus W. Weissmann http://www.mweissmann.de/
On the other hand, I just tried installing bittorrent and it built with python2.4, while the py-wxwidgets port built on python2.5, so the py-* is already broken, with some py-* ports building against 2.4 and others against 2.5. BTW: AFAIK for the GNOME (py-gobject, py-gtk, py-orbit, etc) python ports, pay attention to the GNOME developers--they want to switch the entire GNOME python stack from 2.4 to 2.5 at one time. On 18 Feb 2007, at 12:39, Markus Weissmann wrote:
On 18.02.2007, at 17:47, Yves de Champlain wrote:
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
Revision 22092 <http://trac.macosforge.org/projects/macports/ changeset/22092> Author mww@macports.org <mailto:mww@macports.org> Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007)
Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question.
I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration.
But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ?
Depends: If the port just needs "some" python interpreter at run time, you don't need a py- named port at all, so are just for python modules. For python modules the problem is, that they install themselves in $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or taken 2.3 into account: three) directories, or at least I wouldn't try to - there is code that works with 2.4 but not 2.5 and vice versa, so we'll run into problems here, sooner or later.
Currently our "main" python is v2.4 and I'd say we'd stay with that at least until 2.5.1 is out. But even then there is software that only will work with 2.4, so please don't move py- (2.4) ports to py25- (2.5) ones. If you need a python 2.5 version of that module, duplicate the port. Duplicates are fine here, as I'd expect that some modules will switch to 2.5 compatible code so we will probably have something like this in the future: py-module, version 1.8 py25-module, version 2.2
So we should approach this "switch" slowly, duplicating all the modules we need for 2.5 - if they work. In some years we probably can then nuke the py- (2.4) modules when the py41 ports take over... ;)
cheers,
-Markus
-- Markus W. Weissmann http://www.mweissmann.de/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On 18.02.2007, at 20:36, Randall Wood wrote:
On the other hand, I just tried installing bittorrent and it built with python2.4, while the py-wxwidgets port built on python2.5, so the py-* is already broken, with some py-* ports building against 2.4 and others against 2.5.
BTW: AFAIK for the GNOME (py-gobject, py-gtk, py-orbit, etc) python ports, pay attention to the GNOME developers--they want to switch the entire GNOME python stack from 2.4 to 2.5 at one time.
well, o.k. - the py-wxwidgets port has the wrong dependency. This stems from our missing policy - if we had this documented, we lost it during our transition to macosforge. But just because we made one mistake, doesn't mean this policy is flawed and no policy is better. If the GNOME developers want to switch to 2.5, we should create py25- ports for all (new) GNOME stuff and remove the old ones. There is no advantage in keeping the old names - this will just confuse everyone. -Markus
On 18 Feb 2007, at 12:39, Markus Weissmann wrote:
On 18.02.2007, at 17:47, Yves de Champlain wrote:
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
> Revision > 22092 <http://trac.macosforge.org/projects/macports/ > changeset/22092> > Author > mww@macports.org <mailto:mww@macports.org> > Date > 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007) > > > Log Message > > new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question.
I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration.
But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ?
Depends: If the port just needs "some" python interpreter at run time, you don't need a py- named port at all, so are just for python modules. For python modules the problem is, that they install themselves in $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or taken 2.3 into account: three) directories, or at least I wouldn't try to - there is code that works with 2.4 but not 2.5 and vice versa, so we'll run into problems here, sooner or later.
Currently our "main" python is v2.4 and I'd say we'd stay with that at least until 2.5.1 is out. But even then there is software that only will work with 2.4, so please don't move py- (2.4) ports to py25- (2.5) ones. If you need a python 2.5 version of that module, duplicate the port. Duplicates are fine here, as I'd expect that some modules will switch to 2.5 compatible code so we will probably have something like this in the future: py-module, version 1.8 py25-module, version 2.2
So we should approach this "switch" slowly, duplicating all the modules we need for 2.5 - if they work. In some years we probably can then nuke the py- (2.4) modules when the py41 ports take over... ;)
cheers,
-Markus
-- Markus W. Weissmann http://www.mweissmann.de/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com
"The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
--- Markus W. Weissmann http://www.mweissmann.de/
On 18.2.2007, at 19.39, Markus Weissmann wrote:
On 18.02.2007, at 17:47, Yves de Champlain wrote:
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
Revision 22092 <http://trac.macosforge.org/projects/macports/ changeset/22092> Author mww@macports.org <mailto:mww@macports.org> Date 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007)
Log Message
new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question.
I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration.
But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ?
Depends: If the port just needs "some" python interpreter at run time, you don't need a py- named port at all, so are just for python modules. For python modules the problem is, that they install themselves in $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or taken 2.3 into account: three) directories, or at least I wouldn't try to - there is code that works with 2.4 but not 2.5 and vice versa, so we'll run into problems here, sooner or later.
Currently our "main" python is v2.4 and I'd say we'd stay with that at least until 2.5.1 is out. But even then there is software that only will work with 2.4, so please don't move py- (2.4) ports to py25- (2.5) ones. If you need a python 2.5 version of that module, duplicate the port. Duplicates are fine here, as I'd expect that some modules will switch to 2.5 compatible code so we will probably have something like this in the future: py-module, version 1.8 py25-module, version 2.2
So we should approach this "switch" slowly, duplicating all the modules we need for 2.5 - if they work. In some years we probably can then nuke the py- (2.4) modules when the py41 ports take over... ;)
cheers,
-Markus
-- Markus W. Weissmann http://www.mweissmann.de/ Well, I beg to differ once again (though I am not sure it makes any difference). The ports with no version number should always be for the latest versions. If ports are duplicated or version-dependent ports are written, they should always be for previous versions that for one reason or other are incompatible. The structure should be simple and consistent (e.g. like in the system frameworks), that benefits us all. But again, I do not make the decisions here (though if all ports are handled like this, what is the result).
! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
On 20.02.2007, at 11:44, Jyrki Wahlstedt wrote:
On 18.2.2007, at 19.39, Markus Weissmann wrote:
On 18.02.2007, at 17:47, Yves de Champlain wrote:
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
> Revision > 22092 <http://trac.macosforge.org/projects/macports/ > changeset/22092> > Author > mww@macports.org <mailto:mww@macports.org> > Date > 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007) > > > Log Message > > new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question.
I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration.
But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ?
Depends: If the port just needs "some" python interpreter at run time, you don't need a py- named port at all, so are just for python modules. For python modules the problem is, that they install themselves in $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or taken 2.3 into account: three) directories, or at least I wouldn't try to - there is code that works with 2.4 but not 2.5 and vice versa, so we'll run into problems here, sooner or later.
Currently our "main" python is v2.4 and I'd say we'd stay with that at least until 2.5.1 is out. But even then there is software that only will work with 2.4, so please don't move py- (2.4) ports to py25- (2.5) ones. If you need a python 2.5 version of that module, duplicate the port. Duplicates are fine here, as I'd expect that some modules will switch to 2.5 compatible code so we will probably have something like this in the future: py-module, version 1.8 py25-module, version 2.2
So we should approach this "switch" slowly, duplicating all the modules we need for 2.5 - if they work. In some years we probably can then nuke the py- (2.4) modules when the py41 ports take over... ;)
cheers,
-Markus
Well, I beg to differ once again (though I am not sure it makes any difference). The ports with no version number should always be for the latest versions. If ports are duplicated or version-dependent ports are written, they should always be for previous versions that for one reason or other are incompatible. The structure should be simple and consistent (e.g. like in the system frameworks), that benefits us all. But again, I do not make the decisions here (though if all ports are handled like this, what is the result).
I'm sure we all want the best solution and that's why we are discussing this - my arguments weren't meant to be dictatorial decisions from above... ;) But back on topic: I think you are right in that it is not obvious that the prefix "py-" is connected to Python 2.4, while py25- is to 2.5 (and where the hell are the py24- ports?) In a perfect world and if we still were in the planning phase, I'd totally agree with you on that one. Point is though, that we already have some hundred ports prefixed "py-" that use Python 2.4. If we silently change even just some of those, users will be surprised and probably pissed. We have two ways out of this dilemma: (i) Make a major announcement and rename all current "py-" ports to "py24-" or (ii) leave the "py-" ones like they are and make it better with the "py25-" ports. For the least-surprise for existing users (and existing ports that depend on Python modules) I am in favor of the second model - and also because this is _way_ less work for us. Perhaps there is a third possibility I missed or a killer argument for (i) - I'm open to good alternatives. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
Jyrki Wahlstedt wrote:
On 18.2.2007, at 19.39, Markus Weissmann wrote:
On 18.02.2007, at 17:47, Yves de Champlain wrote:
Le 07-02-17 à 14:15, Blair Zajac a écrit :
Yves de Champlain wrote:
Le 07-02-17 à 11:32, Yves de Champlain a écrit :
Le 07-02-17 à 11:18, source_changes@macosforge.org <mailto:source_changes@macosforge.org> a écrit :
> Revision > 22092 > <http://trac.macosforge.org/projects/macports/changeset/22092> > Author > mww@macports.org <mailto:mww@macports.org> > Date > 2007-02-17 08:18:26 -0800 (Sat, 17 Feb 2007) > > > Log Message > > new port py25-bz2 - python 2.5 bindings to bzip2
I am a bit confused. Python 2.5 is presented as current production version on python.org, but these commits make it look like a special case. Is there some sort of problem with python 2.5 on Mac ? Or is this a problem with how python is managed in MacPorts ?
Just let me be a little more precise : could there be py24-* and py25-* ports for python ports that use a specific PortGroup and py-* ports for python packages that don't use a PortGroup ?
But wouldn't that require the Python builds to have a common shared place to look for non-binary modules, so we only have to depend upon one port. Also, non-binary modules that depends upon binary modules would still need to be versioned for each version of Python, I think :)
Yes, that is part of the question.
I maintain a few python ports (gtk2, gobject and cairo) while not being really proficient with python setup and configuration.
But these ports don't belong to a portgroup but rather look for python through a configure script and will accept both 2.4 and 2.5, so should I still make py25 versions of them ?
Depends: If the port just needs "some" python interpreter at run time, you don't need a py- named port at all, so are just for python modules. For python modules the problem is, that they install themselves in $prefix/lib/python2.4/ (or 2.5); we can't unify those two (or taken 2.3 into account: three) directories, or at least I wouldn't try to - there is code that works with 2.4 but not 2.5 and vice versa, so we'll run into problems here, sooner or later.
Currently our "main" python is v2.4 and I'd say we'd stay with that at least until 2.5.1 is out. But even then there is software that only will work with 2.4, so please don't move py- (2.4) ports to py25- (2.5) ones. If you need a python 2.5 version of that module, duplicate the port. Duplicates are fine here, as I'd expect that some modules will switch to 2.5 compatible code so we will probably have something like this in the future: py-module, version 1.8 py25-module, version 2.2
So we should approach this "switch" slowly, duplicating all the modules we need for 2.5 - if they work. In some years we probably can then nuke the py- (2.4) modules when the py41 ports take over... ;)
cheers,
-Markus
-- Markus W. Weissmann http://www.mweissmann.de/ Well, I beg to differ once again (though I am not sure it makes any difference). The ports with no version number should always be for the latest versions. If ports are duplicated or version-dependent ports are written, they should always be for previous versions that for one reason or other are incompatible. The structure should be simple and consistent (e.g. like in the system frameworks), that benefits us all. But again, I do not make the decisions here (though if all ports are handled like this, what is the result).
I disagree that the non-versioned py or pm modules should be the latest version. While this is nice, in practice, it requires a forklift upgrade of all the Python modules and I don't see it working that well unless one or two people want to take on upgrading all the modules. Then, it would also be nice to have the same modules on the old version of Python for people who don't want to move to the latest version of Python for whatever reason, say they have their own private Portfiles for local modules. So I would rather see all modules with a version name in them. BTW, where I'm coming from is using MacPorts in for commercial products or in a corporate environment deployed to 100's of Mac desktops where you need to support multiple versions of Python simultaneously. I'm not looking at MacPorts just for my own personal use on a laptop, where these issues are not as important. Regards, Blair
Le 07-02-22 à 11:05, Blair Zajac a écrit :
Jyrki Wahlstedt wrote:
On 18.2.2007, at 19.39, Markus Weissmann wrote:
skip ...
Well, I beg to differ once again (though I am not sure it makes any difference). The ports with no version number should always be for the latest versions. If ports are duplicated or version-dependent ports are written, they should always be for previous versions that for one reason or other are incompatible. The structure should be simple and consistent (e.g. like in the system frameworks), that benefits us all. But again, I do not make the decisions here (though if all ports are handled like this, what is the result).
I disagree that the non-versioned py or pm modules should be the latest version. While this is nice, in practice, it requires a forklift upgrade of all the Python modules and I don't see it working that well unless one or two people want to take on upgrading all the modules.
Then, it would also be nice to have the same modules on the old version of Python for people who don't want to move to the latest version of Python for whatever reason, say they have their own private Portfiles for local modules. So I would rather see all modules with a version name in them.
BTW, where I'm coming from is using MacPorts in for commercial products or in a corporate environment deployed to 100's of Mac desktops where you need to support multiple versions of Python simultaneously. I'm not looking at MacPorts just for my own personal use on a laptop, where these issues are not as important.
I guess then the best solution is to have, ultimately, no py- ports at all, because they only cause confusion, but rather only py25 py26 py30 etc. Then there will be only one question left ... which python port gets to have the great python symlink in bin ? yves
Yves de Champlain wrote:
Le 07-02-22 à 11:05, Blair Zajac a écrit :
Jyrki Wahlstedt wrote:
On 18.2.2007, at 19.39, Markus Weissmann wrote:
skip ...
Well, I beg to differ once again (though I am not sure it makes any difference). The ports with no version number should always be for the latest versions. If ports are duplicated or version-dependent ports are written, they should always be for previous versions that for one reason or other are incompatible. The structure should be simple and consistent (e.g. like in the system frameworks), that benefits us all. But again, I do not make the decisions here (though if all ports are handled like this, what is the result).
I disagree that the non-versioned py or pm modules should be the latest version. While this is nice, in practice, it requires a forklift upgrade of all the Python modules and I don't see it working that well unless one or two people want to take on upgrading all the modules.
Then, it would also be nice to have the same modules on the old version of Python for people who don't want to move to the latest version of Python for whatever reason, say they have their own private Portfiles for local modules. So I would rather see all modules with a version name in them.
BTW, where I'm coming from is using MacPorts in for commercial products or in a corporate environment deployed to 100's of Mac desktops where you need to support multiple versions of Python simultaneously. I'm not looking at MacPorts just for my own personal use on a laptop, where these issues are not as important.
I guess then the best solution is to have, ultimately, no py- ports at all, because they only cause confusion, but rather only py25 py26 py30 etc.
Then there will be only one question left ... which python port gets to have the great python symlink in bin ?
We could supply two Portfiles that provide this and the MacPorts administrator can decide which one to make the default. Regards, Blair
participants (6)
-
Blair Zajac
-
Jyrki Wahlstedt
-
Markus Weissmann
-
Randall Wood
-
Weissmann Markus
-
Yves de Champlain