Michael Schutte <mi...@uiae.at> writes:
> The binary package is currently called python-odtwriter; after a
> discussion in February 2008 [1], I decided to stick with this name.
I participated in that discussion, but I find that my position has
changed.
> In the meantime, docutils-writer-manpage entered the archive (Ben
> Finney). It obviously uses a completely different naming scheme and
> provides a small rst2man binary package which only contains the
> frontend. And then there is rst2pdf (Chris Lamb) which does the
> all-in-one thing in a single eponymous .deb.
>
> Since I care about consistency, I’d like to get this sorted out.
I applaud this desire for consistency and concur.
> My personal preference would be “python-docutils-X”: it’s short,
> reasonably precise and explanatory. How do you think these packages
> should be called? Any input is welcome, even if it’s just “it
> doesn’t matter.”
Here's my reasoning.
I no longer think ‘python-’ is an appropriate prefix for the package
name. These packages are primarily components of Docutils, so they are
“private” in that they are entirely within the context of Docutils.
Since they're not a general-use Python module, the package shouldn't
be named like one.
So I think the following naming style is appropriate:
docutils-reader-foo
docutils-reader-bar
docutils-transform-wibble
docutils-transform-wobble
docutils-writer-quux
docutils-writer-xyzzy
These are components of the Docutils system; and such extensions can
be of several distinct purposes (hence “reader”, “transform”,
“writer”, etc.) Once all that's said, the rest of the name should be
answering the question “A Docutils writer for what?” (likewise for
reader, transform, etc.)
To my knowledge there are not yet any Docutils components other than
writers packaged; but the Docutils design explicitly allows for
third-party components of many different kinds (with different
purposes, which means they would be best grouped together under
similar names).
The component is best packaged as a library, separate from the main
tool (if any) that uses that library. Either that, or the library
package which includes an executable tool should ‘Provides: ’ a
virtual package for that tool so that the user can find it by the
logical name; this also allows an easier user migration to packaging
them separately if that decision is revisited.
For the existing components and front-end tools, I would like to see
these package names:
docutils-writer-odt
rst2odt
docutils-writer-pdf
rst2pdf
docutils-writer-manpage
rst2man
docutils-writer-website
rest2web
docutils-writer-sphinx
sphinx
--
\ “Pinky, are you pondering what I'm pondering?” “Um, I think so, |
`\ Brainie, but why would anyone want to Pierce Brosnan?” —_Pinky |
_o__) and The Brain_ |
Ben Finney
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
