Ryan Stonecipher wrote:
> Anders,
> How does one determine if a python-based library is a "module"? Are libraries
> binding python commands to external libraries "modules"? If your answer
> might help other developers determine when to split a port into py*-foo
> rather than making port foo with py* variants, please feel free to CC the
> -dev list.
I would say that a module is something that installs into "site-packages" (or
"dist-packages"). But some of those also install programs, so it's not an
absolute definition.
The problem here comes when you need the same module for more than one Python
version. The actual module is not the problem, since it comes in a versioned
directory like lib/python2.5 or Library/Python/2.5, but that it might install
unversioned programs that would conflict with the same module from 2.4 or 2.6
or 2.7. Thus it's usually better to have one port for a program, even if it
uses python. But if it's just a module ("library"), then it might need one for
each python. Since some programs use one version, and other programs use
another.
It's not a very pretty situation. Other languages can use modules from older
versions, and other build systems can automatically append the python version.
But for MacPorts, you need to depend on a specific version (like "python26")
and then patch all shebangs (to "python2.6"). And when you need a module, and
you need to make sure that too is available (as "py26-foo") even if it was
already installed for another version (as "py25-foo"). This gets especially bad
when your poor program isn't written mainly in Python, but only supports or
uses it (e.g. RPM).
For some software, the best solution is to *split* into several packages (one
"program", one "module"). But there is no support for that either, so needs to
be done manually.
--anders
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
