Re: private modules and dh_python2
[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
Reply to: