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

[Emmanuel Hainry]

Hi,

I think this is a nice idea. It could take inspiration on what is done
by other package systems.

Citando Weissmann Markus :
> 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.

For the third case, the "old" dependency sheme permits this : rubber
depends on a binary called python, but not explicitly the one provided
by python23 which was the latest at the time of the first portfile for
rubber. For the first case, it looks like pkgsrc's /etc/mk.conf which
can contain 'PYTHON_VERSION_DEFAULT=24' (or 25).

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

And you would call it port_alternatives, just like pkgsrc's
pkg_alternatives or debian's alternatives.

'pkg_alternatives change vi vim' says that the meta vi is now provided
by vim. 

Both use a config directory that contains symlink to the selected
programs providing the alternative. And the main link points to the
config directory. The added value here would be the possibility to
select apple's tools. So, python, editor, gcc, ruby, perl would already
have available alternative, whereas text-browser would not. 

One point it raises is the fact that some ports *provide* some
functionality (browser for example, sql database for another one) and
that other port may depend on that functionality. This point is similar
to the idea of a virtual postgresql or mysql package provided by one of
the numerous available ports, and ports being able to depend on that
virtual package whose variants tell to which of the possible port to
link the mysql to be used.

> 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?
> 

Sorry, not me, but I would be interested that it be implemented.

> 
> cheers,
> 
> -Markus
> 
> 
> 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).
> 

Emmanuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070323/8eb64f4c/attachment.bin