Project organization and import

[Chris Mellon]

On 6 Mar 2007 10:30:03 -0800, Martin Unsal <martinunsal at gmail.com> wrote:
> 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.
>

Theres a number of solutions. They do involve manipulation of
PYTHONPATH or creation of infrastructure, though. I find that I
generally work "against" only one version of package at a time, so
it's not any trouble for me to create a local directory that has all
the version I'm working against. Testing infrastructure manipulates
PYTHONPATH to ensure it's testing the version its supposed to.

> > 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.
>

If you have lots of modules used by lots of "things" it can be. Not
necessarily though, it depends on how you package and deploy them.
It's often the best solution to the above issue when it comes to
testing, though.

> > 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? :)
>

Then its a subpackage of a parent package. That's different than just
walking up to wherever your did your RCS checkout.

> 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).
>

Environment and manipulation of it is the job of the top level
script/application/whatever. Modules/packages/whatever should rely on
PYTHONPATH being sane.

> Martin
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>