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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev