Project organization and import

[Martin Unsal]

On Mar 6, 9:34 am, "Chris Mellon" <arka... at gmail.com> wrote:
> It assumes that util.common is a module thats on the PYTHONPATH.

Now we're getting somewhere. :)

> The common way to ensure that this is the case is either to handle
> util as a separate project, and install it into the system
> site-packages just as you would any third party package,

This breaks if you ever need to test more than one branch of the same
code base. I use a release branch and a development branch. Only the
release branch goes into site-packages, but obviously I do most of my
work in the development branch.

> or to have it
> (and all your other application packages and modules) off a single
> root which is where your your application "base" scripts live.

This has SERIOUS scaling problems.

> This, and other intra-package import issues are affected by the
> relative/absolute import changes that were begun in Python 2.5, you
> can read about them here:http://www.python.org/dev/peps/pep-0328/

Awesome! Thanks. I'll take a look.

> Note that using relative imports to import a package that "happens" to
> be share a common higher level directory would be frowned upon.

What if it shares a common higher level directory by design? :)

Relative imports aren't ideal, but I think in some cases it's better
than relying on PYTHONPATH which is global state (an environment
variable no less).

Martin