ImportError depending on the calling module
knipknap at gmail.com
Thu Sep 6 19:41:42 CEST 2007
On Sep 6, 6:44 pm, Gabriel Genellina <gagsl-... at yahoo.com.ar> wrote:
> On 6 sep, 13:13, Samuel <knipk... at gmail.com> wrote:
> > On Sep 6, 5:44 pm, Gabriel Genellina <gagsl-... at yahoo.com.ar> wrote:
> > > They should import the package as any other
> > > client code, without doing any import tricks nor playing with
> > > sys.path.
> > Why does it matter whether I install it in sys.path or whether
> > sys.path is modified? What's the difference?
> Because it's more simple, less error prone, easier to test, more
> > What I am doing is I ship two modules in one tarball with my software.
> > The software is only unpacked and ran. It has to work without
> > installation.
> That's fine, and a good requirement. Place start2.py inside the
> container directory, and your package beneath it. Then you don't have
> to modify sys.path to find the package - "import packagename" just
> works. And it still works if the user installs the package (into site-
> packages, by example).
> |-- Obj.py
> |-- __init__.py
> |-- foo/
> |-- FooTest.py
> `-- __init__.py
> Packages are... well, packages, boxes. Don't try to import a module
> inside a package as it were a standalone module
But the start2.py script *is* part of the library. It should be in the
However, I just found that Python 2.5 introduces relative imports.
This sounds like an attempt to remedy the situation.
More information about the Python-list