Project organization and import

[Chris Mellon]

On 6 Mar 2007 09:24:32 -0800, Martin Unsal <martinunsal at gmail.com> wrote:
> On Mar 6, 8:56 am, "Chris Mellon" <arka... at gmail.com> wrote:
> > Scrollbar *can't* assume that util will be present in its namespace,
> > because it won't be unless it imports it. Scrollbar needs to import
> > its own dependencies. But why do you think thats a problem?
>
> OK, maybe I'm totally missing something here, but you can't do
> "import ../util/common" in Python can you?
>
> Look at the directory structure in my original post. How does
> Scrollbar.py import its dependencies from common.py, without relying
> on PYTHONPATH?
>

It assumes that util.common is a module thats on the PYTHONPATH.

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, 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, 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/

Note that using relative imports to import a package that "happens" to
be share a common higher level directory would be frowned upon. The
"blessed" mechanism would still be to use an absolute import, and to
install the other package on the PYTHONPATH in one of any number of
ways.