[Eike Nicklas, 2011-06-10] > I just tried to package an application using a private module. In this > case, the name of the script starting the application and the module > have the same name. > > So if the module is in /usr/share/foo/foo, then the script can not > be /usr/share/foo/foo as well and installing the script > to /usr/share/foo/scripts/foo results in an import error.
install foo to /usr/share/foo/ under a different name, see http://lists.debian.org/debian-python/2009/03/msg00091.html > 1) Patch the upstream script to add /usr/share/foo to pythonpath if > 'import foo' fails? try to avoid patching > 2) In this specific case (which might actually not be that uncommon), > dh_python2 could rename the script foo to foo.py such that it can be > installed to /usr/share/foo/foo.py (currently, the behavior of > dh_python2 is to install the script to /usr/share/foo/foo/foo in this > case of a naming clash). renaming foo to foo.py is not a good idea, IMO (if there's a foo package (as in foo/__init__.py) it still will be imported, but it's unnecessary confusion. Just name it: "run", "start", "init" or something like this. The name doesn't really matter since you will link it as /usr/bin/foo later anyway > 3) Module and script having the same name is bad practice and the > module should be renamed to foo-lib anyway. that's ugly (even when you remove the unaccepted "-") - I find all these "foolib" or "pyfoo" module names ugly (isn't it obvious that this module is a library or that it's for Python?) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110610195211.gr24...@piotro.eu