Thanks for the feedback. I did rewrite this a little bit, so hopefully it's
clearer. I left some of the text in there because at least to me it reads
better and provides some rationale for why the rules are there. But hey, it's
a wiki so please feel free to make further improvements!
Cheers,
-Barry
On Oct 07, 2015, at 11:34 PM, Piotr Ożarowski wrote:
>[Debian Wiki, 2015-10-07]
>> https://wiki.debian.org/Python/LibraryStyleGuide?action=diff&rev1=64&rev2=65
>>
>>
>> == Gotchas ==
>>
>> + === Executables and library packages ===
>> +
>> + Let's say you have a Python package which results in Python 2 and 3
>> libraries, and a Python 3 executable. What is the best practices for naming
>> and organizing your binary packages?
>> +
>> + Clearly you want to have:
>> +
>> + * python-foo -- the Python 2 library
>> + * python3-foo -- the Python 3 library
>
> * foo -- for the executable (and possible additional dependencies that
> library doesn't need)
>
>maybe extent it to:
>
> * python-foo -- the Python 2 library (and Python 2.X scripts if they're
> Python 2.X specific)
> * python3-foo -- the Python 3 library (and Python 3.X scripts if they're
> Python 3.X specific)
>
>> +
>> + but where should the `/usr/bin/foo` script go? You could put it in
>> `python3-foo` but you '''CANNOT''' put it in `python-foo` or for that matter
>> any binary package that starts with the `python-` prefix. `dh_python3`
>> refuses to rewrite shebang lines for any executable in a binary package that
>> starts with "python-" or "pypy-". This means that something like
>> `python-foo-cli` or `python-foo-bin` is unacceptable.
>
>I'd remove this part - it's not dh_python3 specific (dh_python2 and
>dh_pypy does similar things) and I don't think such corner case should
>be in style guide
>
>> +
>> + Here are some recommendations. We do not have a standard (though maybe we
>> should):
>> +
>> + * `foo` - this is nice if it parallels the /usr/bin/foo name but it might
>> collide with existing packages, and some people don't like to make such a
>> claim on an unadorned top level package
>> + * `python3-foo-cli` or `python3-foo-bin` - not as nicely discoverable,
>> but `command-not-found` can help, and dh_python3 will work
>
>if someone creates python3-foo-cli binary just to ship /usr/bin/foo it
>might as well be foo (if there are no /usr/bin/foo name collisions,
>binary package name should be safe as well) so I'd remove it
pgpT040WQ7qgL.pgp
Description: OpenPGP digital signature