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 derek.