ImportError depending on the calling module

[Samuel]

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
> efficient...
>
> > 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).
>
>  start1.py
>  start2.py
>  packagename/
>  |-- 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
package.
However, I just found that Python 2.5 introduces relative imports.
This sounds like an attempt to remedy the situation.

-Samuel