On 06/08/15 15:50, Barry Warsaw wrote:
> The example that sparked issue #751908 was tox, which when I initially
> packaged it, I called the binary package python-tox. I did this because,
> while the package does not provide any publicly importable modules, I felt it
> was presumptuous to claim a rather generic name like 'tox' as the binary
> package.
If it's pollution in the flat namespace of packages, then it's pollution
in the flat namespace of "what's in $PATH". If it isn't, it isn't. Pick
one? :-)
> Should there be a naming convention for Python packages which only provide an
> executable?
Policy has this to say on the subject of a different flat global namespace:
"When scripts are installed into a directory in the system PATH, the
script name should not include an extension such as .sh or .pl that
denotes the scripting language currently used to implement it."
Does similar reasoning make sense for package names - the user of the
package is looking for the functionality of the package, not the
implementation language?
If disambiguation is needed due to a naming conflict, a descriptive
prefix/suffix might make more sense: "tox-tester" or "tox-python-tester"
would be in the same spirit as chromium-browser (now chromium) vs. the
game Chromium B.S.U. (now chromium-bsu), and nodejs vs. ax25-node
fighting over "node". (Note the subtle distinction that nodejs is *for
use with* JavaScript, not *written in* JavaScript.)
S
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c37b4a.90...@debian.org
