Python dynamic import path

Question

G'day,

Being a total python noob when it comes to packaging and module organisation..

Given the following (simplified) structure:

.
├── bin
│  └── fos.py
└── lib
 └── drac.py

And the fact, that when installed, contents of lib folder will go somewhere into /usr/local/share/pyshared and contents of bin folder somewhere in /usr/bin, how do I persuade this whole thing to import my modules from ../lib when in VCS mode and work like it should, i.e. from modulename.drac import bla when installed, while keeping imports preferably the same?

Yes, I've read python docs on module organisation and structure, I just can't seem to wrap my head around some best practices. Asking for best practices on SO is stupid, hence this concrete example, which I have on a daily basis more or less.

Is this structure acceptable, if so, how do I organise the imports? If not, what would be the pythonic way to redo it?

Thanks!

Answer 1

I think you are bucking the idiom here. What you are describing is similiar to the old c ld_lib paradigm.

There is nothing wrong with a python project sourcing modules out of its own local file tree. Alternatively if your code is really that separate and your lib has a well defined API then you should package it separately and import/install it using ez_install, pip, or a setup.py

Generally if the code appears to be evolving together it best to just leave it together. Install it wherever you install your python code (opt..etc.) And symbolically link executables into /usr/local/bin

• favoretti: The reason I'm after this kind of structure, is that I generally package stuff for different UNIX distro's. Hence, lib separately, binaries separately. Normal packages to UNIX need to place lib parts generally speaking under /usr/share, wherease binaries under /usr/bin. I know this might be alien to python module packaging paradigm, but python being THE tool for system administrators should have a way to package contrib "binaries" from the lib code? :) And yes, lib is separate, binary is separate, but packaging 1 python file into a separate UNIX package seems like a huge overkill.
• favoretti: Think of it in the context of a python library with a command-line interface to use some parts of it :)
• nsfyn55: Yeah but once again that paradigm assumes that you are setting up for a linking step. Python has something similiar to a linking step(for finding imported modules) but it works very differently. If you look at the way the dpkg for node and npm work they are similar to what I described in my answer. They deploy the whole shebang into the lib or share folder then symbolically link the related executables into /usr/local/bin.
• nsfyn55: a lot of that stuff is weird lsb stuff that isn't as relevant as it once was. ducks flying vegetables.
• favoretti: Hmm, yeah, that probably makes sense. No vegetables here, just 20 years of legacy mindset :) Thanks man, you gave me a fresh perspective.