Modules vs Bindings

[Anders F Björklund]

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