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, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> a écrit :
Revision
22092
<http://trac.macosforge.org/projects/macports/changeset/22092>
Author
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
