On Sep 6, 6:44 pm, Gabriel Genellina <[EMAIL PROTECTED]> wrote: > On 6 sep, 13:13, Samuel <[EMAIL PROTECTED]> wrote: > > > On Sep 6, 5:44 pm, Gabriel Genellina <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
