On 30/04/12 15:50, Barry Warsaw wrote:
> On Apr 30, 2012, at 12:08 PM, Simon McVittie wrote:
>> I think it would still be clearer to say
>> /usr/share/package-name/module.py, /usr/lib/package-name/module.so,
>> assuming the library-user code involves "import module"?
>
> Debian "package-name" or Python "package-name"? :)
I meant package-name to be a Debian package name (this terminology
collision is really unfortunate).
>> (Or invent an example like Debian package foo containing Python module
>> foolib, which would lead to something like /usr/share/foo/foolib.py,
>> /usr/lib/foo/foolib.so or /usr/share/foo/foolib/__init__.py, or use a
>> real example like virt-manager or guake)
>
> +1, although the Debian package would be python-foo (or python3-foo) for a
> Python package named foo.
python[3]-foo is the correct name for a Debian package that lets you
"import foo" - but if we were talking about that, it should be a public
Python package. This thread is about private Python packages, where you
can't or shouldn't "import foo" from code outside the (Debian) package,
or a small set of cooperating packages (e.g. an application and its
plugins).
I hope you're not arguing that virt-manager, the Gtk tool for managing
virtual machines, ought to be called python-virtmanager, just because it
happens to be implemented in Python and contain a private Python package
(off the default sys.path) called virtManager?
S
--
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/4f9eba3e.9040...@debian.org
