Refactoring python module configuration to avoid relative imports.

Question

This is related to a previous question of mine.

I understand how to store and read configuration files. There are choices such as ConfigParser and ConfigObj.

Consider this structure for a hypothetical 'eggs' module:

eggs/
  common/
    __init__.py
    config.py
  foo/
    __init__.py
    a.py

'eggs.foo.a' needs some configuration information. What I am currently doing is, in 'a',

import eggs.common.config

. One problem with this is that if 'a' is moved to a deeper level in the module tree, the relative imports break. Absolute imports don't, but they require your module to be on your PYTHONPATH.

A possible alternative to the above absolute import is a relative import. Thus, in 'a',

import .common.config

Without debating the merits of relative vs absolute imports, I was wondering about other possible solutions?

edit- Removed the VCS context

Answer 1

require statement from pkg_resources maybe what you need.

Answer 2

As I understand it from this and previous questions you only need one path to be in sys.path. If we are talking about git as VCS (mentioned in previous question) when only one branch is checked out at any time (single working directory). You can switch, merge branches as frequently as you like.

Answer 3

I'm thinking of something along the lines of a more 'push-based' kind of solution. Instead of importing the shared objects (be they for configuration, or utility functions of some sort), have the top-level init export it, and each intermediate init import it from the layer above, and immediately re-export it.

I'm not sure if I've got the python terminology right, please correct me if I'm wrong.

Like this, any module that needs to use the shared object(which in the context of this example represents configuration information) simply imports it from the init at its own level.

Does this sound sensible/feasible?

Answer 4

"imports ... require your module to be on your PYTHONPATH"

Right.

So, what's wrong with setting PYTHONPATH?

Answer 5

You can trick the import mechanism, by adding each subdirectory to egg/__init__.py:

__path__.append(__path__[0]+"\\common")
__path__.append(__path__[0]+"\\foo")

then, you simply import all modules from the egg namespace; e.g. import egg.bar (provided you have file egg/foo/bar.py).
Note that foo and common should not be a package - in other words, they should not contain __init__.py file.

This solution completely solves the issue of eventually moving files around; however it flattens the namespace and therefore it may not be as good, especially in big projects - personally, I prefer full name resolution.