Package organization: where to put 'common' modules?

[Paul Boddie]

fortepianissimo wrote:
> Paul Boddie wrote:
> > fortepianissimo wrote:
> > > Hm this doesn't work. Say I have the following directory structure:
> > >
> > > A
> > > |--- util
> > > |    |--- foo.py
> > > |
> > > |--- B
> > >      |--- bar.py
> > >
> > >
> > > And bar.py has this line
> > >
> > > from util import foo

[...]

> Placing code modifying sys.path in main would be a problem if the
> utility loading line is at the beginning of the module - error would
> occur before sys.path can be modified.

Well, I suppose you could start your module with...

import sys, os
sys.path.append(some_nasty_tricks_with_paths)

Although I don't really recommend this, since such code is going to get
run as the modules get imported, and this could cause some additional
complications if various things then conspire to import the "wrong"
modules somewhere else in your system.

> It is especially true for me since I need to load these "common
> functionality" not just for testing - they are necessary to implement
> the functionality of the module.
>
> Besides, adding code to manipulate sys.path in *every* module that
> needs the common functionality module seems to be quite a hassle...

I suppose you're one of the people who may benefit from the relative
import mechanisms in Python 2.5. Myself, I can't see why it's so hard
to write...

from A.util import foo

[...]

> I need to import this common functionality not just for testing code,
> so it probably doesn't matter if I separate the testing code from the
> module itself.

I stopped running modules inside packages directly precisely because of
the behaviour you've seen. I haven't experienced many problems with my
"test from the outside" approach since.

> In addition, the "common functionality" is "common" only for the system
> I'm building - they are probably not that useful for general purposes.
> So placing them in an absolute path (like site packages) doesn't make a
> lot of sense.

Right. So it's just a matter of making sure that everything can import
such functionality without either triggering circular imports or mixing
up "internal" modules with "external" ones (as my example showed).

Paul