Proposal: select tool for python, gcc, swi-prolog, etc.

Weissmann Markus mww at
Fri Mar 23 10:43:18 PDT 2007

Hi all,

here is a proposal to solve the "I don't like the program X to be  
called Y" problem. This problem normally looks like: A prefers Python  
2.4 to be called when "python" is executed, while B prefers Python  
2.5 in this case. Meanwhile C complains that for a silly python  
script a while python installation is compiled on his poor G3 ibook  
when there is Apple's python which would work just fine.
I already saw the same pattern for gcc, coreutils, gnutar, sed, swi- 
prolog, etc.

To overcome this, we should install tools much like Apple's  
"gcc_select" which own the executables (e. g. ${prefix}/bin/python)  
and perhaps stuff like their manpages (e. g. ${prefix}/share/man/man1/ 
python.1.gz). They will carry the generic name as portname (e. g.  
Python). When their script is called, they take the version number  
(or special name - swi-prolog vs. swi-prolog-lite), check if the  
special files (e. g. ${prefix}/bin/python2.5 and ${prefix}/share/man/ 
man1/python25.1.gz) are there and then switch it's symlinks to the  
version specified. In the default case, they would point to Apple's  
version of the tool - if available. It is also possible to switch to  
that version:

$> python -V
Python 2.3.5
$> python_select 2.4
$> python -V
Python 2.4.3
$> python_select 2.5
Python 2.5 is not installed!
$> port install python25
$> pythjon_select 2.5
Python is now Python 2.5
Python 2.5
$> python_select apple
$> python -V
Python 2.3.5

It would be nice if we wouldn't just create multiple tools for all of  
our applications (gcc, python, etc.) but rather find the common  
pattern here. These tools should be installable as normal ports and  
not be part of the base port system.
As an implementation idea: Perhaps creating a generic "select" tool  
that reads a config file depending on the executables name. The  
config file would have the possible interpreters/compilers/.. and  
their respective files to symlink to.

I'm currently out of time, so if someone would like to implement  
this, please shout out loud, so we can find a place to develop this.  
Perhaps this could even be a small to medium task for GSoC?



PS: This would of course mean, that calling ${prefix}/bin/python will  
execute in some random interpreter! Please, if your port relies on a  
specific version of e. g. Python, please specify this _explicitely_  
(call e. g. ${prefix}/bin/python2.4).

Markus W. Weissmann

More information about the macports-dev mailing list