Project organization and import
martinunsal at gmail.com
Tue Mar 6 19:30:03 CET 2007
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).
More information about the Python-list