co-existing pythons?

[Ryan Schmidt]

On Sep 14, 2009, at 09:37, Jack Howarth wrote:

>   Can someone explain the details of how the various
> python packages in MacPorts co-exist? Most of the scientific
> packages I maintained in fink (and will be porting to MacPorts)
> use python/tcltk. I assume MacPorts doesn't really have the
> same type of full python variants as fink where a package can
> be built against any existing compatible python. While full
> python variants are useful, there are limitations to the
> concept. For example, variants really never helped get fink
> transitioned to the tcl 8.5 release. Co-existing tcltk packages
> would have introduced a bewildering number of package variations.
>
> pymol-py25-tcltk84
> pymol-py26-tcltk84
> pymol-py25-tcltk85
> pymol-py26-tcltk25
>
> It even worst in the past before they pruned the pythons to
> be supported in each -py variant.
>   Hopefully the pythons in MacPorts aren't exclusive and
> one doesn't have to be deactived to install the other.

The various python ports and the various python module ports do not  
conflict with one another; they can coexist, and in many cases have  
to, as different ports declare dependencies on different python  
versions.

> In
> fink, the approach is to have multiple python2x packages
> but only one optional python package for python26 which
> provides the %p/bin/python symlink to the python26 executable.
> That actually is useful to have because I ran into at least
> one package, pdb2pqr which simply can't be properly built
> without it seeing a %p/bin/python. Not without heavily
> reworking its configuration scripts.
>                Jack

We have the python_select script. Ideally ports would not require the  
user to have selected a particular python, and would work with $ 
{prefix}/bin/python24 or whatever directly.

> ps In fink, we finally upgraded tcl to 8.5, but only for
> the x86_64 architecture. That also raises the question,
> does MacPort have any way to support package variants
> that are architecture specific? For example having a
> tcl 8.4 for powerpc and i386, but tcl 8.5 for x86_64?
> Or would that have to be achieved through a single
> Portfile?

No, we don't do that kind of thing.

Well, the one exception I can think of is oracle-instantclient, for  
which version 10.1.x is the only version available for PowerPC and  
10.2.x is the only version available for Intel. But Oracle clearly  
doesn't know how to make software so I wouldn't use this port as an  
example for best practices.