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

Attachment: pgpT040WQ7qgL.pgp
Description: OpenPGP digital signature

Reply via email to