Re: Using update-alternatives for /usr/bin provided binaries
Apparently two (mostly orthogonal) problems have been squeezed into a single
bug report:
1) Is the name /usr/bin/coverage appropriate?
IMVHO, no, this name is too generic.
2) Can the alternatives mechanism be used to switch between the two
implementations of the coverage command line tool?
* Dmitry Shachnev <mitya57@gmail.com>, 2013-10-15, 10:04:
Though, #726255 still needs a resolution, and I would like to have the view
of other Python module maintainers. Is using update-alternatives the way to
go? Was my commit correct? Is there any other (better) way to do things here?
I agree with Thomas here. Update-alternatives is a good and standard way to do
such things. For example, we use it in sphinx and python-docutils to provide
tools like sphinx-build or rst2html.
True for docutils; however, sphinx doesn't use alternatives, and it doesn't do
so for good reasons.
The alternatives mechanisms is only suitable if both commands are compatible,
i.e. their behavior doesn't vary with Python version. This is the case for
rst2html and friends, but no so much for sphinx-build. The problem is that
sphinx-build can import 3rd-party Python code, which is not necessarily
compatible with both Python 2 and 3.
As I understand it, python{2,3}-coverage are NOT compatible, and therefore they
should NOT use alternatives.
--
Jakub Wilk
Reply to: