On Sep 6, 2007, at 15:27, Derek Harland wrote:
is there something we can do about these duplicated ports? As we
have
now a python-3.0 devel port there could be much more ports just for
this version.
Wouldn't be a bin:python:python24/25/30 better?
The python ports (python24, python25, python30) could create a
symbolic
link named "python" so it should be there and can be checked.
And for ports which need a specific version we could just check for
that one (bin:python25:python25).
I don't use python. But I believe the idea was that there are
significant differences between python 2.4 and 2.5, and that there is
some software that works with 2.4 but not 2.5, some that works with
2.5 but not 2.4, and some that works with both 2.4 and 2.5 but with
significant changes in how that's done. So the decision was to have
separate portfiles. I have no information on how python 3.0 fits into
the picture now. Perhaps someone who uses python can comment.
The issues are really around how one might support *multiple*
installations of python on a box. For example, I run python2.4 in
production, 2.5 in development and am fiddling around with the SVN
Head of python3.
Thus I might need to install a package for each of these pythons
because:
(i) a python package will want to install itself into the "usual"
place, which is
/opt/local/lib/python2.x/site-packages
(ii) if it contains c-code, it will want to compile itself against
a specific python version as the ABI may change.
(iii) in very rare cases, you might want to be downloading/
compiling a different source file as the author may have released
different versions for 2.4 and 2.5 to take advantage of new
features in 2.5
Its not really sufficient to just check that *python* exists and
install it using that version. Doing so would mean
(i) only that version of python would find it on its default import
path (given above)
(ii) other versions installed by macports would not see it. If you
hacked their import path, you would be importing c-modules compiled
against a different library version and warnings would be issued
This is further complicated by the fact that python3.x is *not*
language compatible with the 2.x branch. It will require library
writers to review their code and definitely issue a separate
release for it (and of course, expect a lot of small little
utilised libraries never to be converted)
Within the macports framework, it would appear that you either need
a separate portfile per python version, or a single portfile with
variants +pythonx.x
Well if the goal is simultaneous installation of multiple versions of
python, then a single portfile with variants is not an option, since
you cannot simultaneously install multiple variant versions of a
single port. Only one version of a port can be active at once. So you
need separate ports, as we have now.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
