Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand z...@debian.org wrote: On 10/15/2013 06:21 PM, Tristan Seligmann wrote: What sort of upstream source code would be using the /usr/bin wrapper at all? (I ask this question without prejudice; I can obviously imagine some ways this might happen, but I'm more interested in the actual existing use cases that you implied, not ones that only exist in my imagination) I'm not sure if you're talking about the *full path* bit or what. Upstream code (or at least, unit tests...) is calling coverage from the standard accessible $PATH. For example: zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage python setup.py testr --coverage Does this really invoke /usr/bin/coverage, as opposed to just importing the coverage module (I'm not familiar with testrepository)? I would have expected most Python tools to just import the module, rather than spawning the wrapper as an external process, hence my original question. (In fact, how would that invocation even work correctly, if it's running with whatever interpreter the `coverage` wrapper uses, rather than the interpreter you invoked setup.py with?) The thing is, we can bikeshed about what *may* happen *in the future*. Though right now, there's a problem which I would like to fix. And that is very easily fixed by providing /usr/bin/coverage, while ugly hacking (because that's what it is about) in all other upstream projects is a much, much harder task. I agree with this; if a naming conflict develops in the future, I don't think renaming things then will be any harder than renaming them now is, and if a conflict never develops, there isn't an issue to begin with. -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMcKhMR3oWC=XLR7e6KRfi_kg=rygfgocuxkgqmdwkcruvs...@mail.gmail.com
Re: Using update-alternatives for /usr/bin provided binaries
I think it's reasonable to get OpenStack to look for python-coverage to run it's tests when using a system package. Or use python -m coverage. 'coverage' is indeed super generic and the precedent within Debian for the package is to call the binary 'python-coverage'. Is there some reason we can't take that approach? -Rob -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj3hoz1ll-0ppj0khd2pw4fbn71bu+e9ouyuernui4mu2ss...@mail.gmail.com
Re: Using update-alternatives for /usr/bin provided binaries
On 10/16/2013 02:20 PM, Robert Collins wrote: I think it's reasonable to get OpenStack to look for python-coverage to run it's tests when using a system package. Or use python -m coverage. 'coverage' is indeed super generic and the precedent within Debian for the package is to call the binary 'python-coverage'. Is there some reason we can't take that approach? -Rob Hi Robert, If you think this way, as an upstream author, then I have to agree. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525e4164.7080...@debian.org
Re: Using update-alternatives for /usr/bin provided binaries
On 10/16/2013 01:52 PM, Tristan Seligmann wrote: On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand z...@debian.org wrote: On 10/15/2013 06:21 PM, Tristan Seligmann wrote: What sort of upstream source code would be using the /usr/bin wrapper at all? (I ask this question without prejudice; I can obviously imagine some ways this might happen, but I'm more interested in the actual existing use cases that you implied, not ones that only exist in my imagination) I'm not sure if you're talking about the *full path* bit or what. Upstream code (or at least, unit tests...) is calling coverage from the standard accessible $PATH. For example: zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage python setup.py testr --coverage Does this really invoke /usr/bin/coverage, as opposed to just importing the coverage module (I'm not familiar with testrepository)? Yes, please look at the beginning of #726255 where I show what happens. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525e423d.6000...@debian.org
Re: Using update-alternatives for /usr/bin provided binaries
Hi all, On Tue, Oct 15, 2013 at 7:08 AM, Thomas Goirand z...@debian.org wrote: 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. However, I don't agree with giving this bug grave severity. There are lots of ways to invoke coverage, i.e. using it from python, or using existing scripts. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKimPHWupd6mF6GFzOgnQyQED4AR6knFg9q2YRGt=v0y4on...@mail.gmail.com
Re: Using update-alternatives for /usr/bin provided binaries
Thomas Goirand z...@debian.org writes: Hi everyone in the Python list! I've been working with Ben Finney on upgrading python-coverage to 3.7. I believe the package was in good shape before the upload My heartfelt thanks to Thomas for working to help me improve the packaging of Coverage 3.7 to the point where it is suitable for release. which uses update-alternatives, like I saw in other python packages (for example, in waitress, and many others). Ben didn't agree with it, he wrote to me on IRC that there is a controversy about it. My disagreement is several-fold: * The binary package ‘python-coverage’ is for Python 2, and ‘python3-coverage’ is for Python 3. These are, as I understand it, deliberately treated as distinct runtime systems in Debian's Python world. So is it correct for both of them to attempt to provide the same command, when in most Python packages we're deliberately naming development tools to have Python 3 explicitly a separate runtime system? * If we're not going to have Python 2 and Python 3 packages attempt to provide the same command name, there doesn't seem much point using the Debian alternatives system. A symlink, as is already used in existing releases of the package, should be sufficient. * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in Debian for a Python-only development tool. This was the reason for renaming the binary ‘/usr/bin/python-coverage’ in every Debian release of the package so far. We both didn't want to hold the update of python-coverage which was really overdue: the last upload was from 2012-05, and version 3.6 (required for many packages) was released early last January. So I went ahead and sponsored the upload of python-coverage 3.7. I'm really glad to see this, and thanks to Thomas for agreeing to get Coverage 3.7 into Debian separately from this mostly-unrelated issue. 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? Please let both Ben and I know your view. Likewise. (I'm subscribed to this forum, and AFAIK Thomas is also, so no need to Cc us on the discussion.) -- \ “I must say that I find television very educational. The minute | `\ somebody turns it on, I go to the library and read a book.” | _o__)—Groucho Marx | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7wa9ibkpg5@benfinney.id.au
Re: Using update-alternatives for /usr/bin provided binaries
On 10/15/2013 02:39 PM, Ben Finney wrote: My disagreement is several-fold: * The binary package ‘python-coverage’ is for Python 2, and ‘python3-coverage’ is for Python 3. These are, as I understand it, deliberately treated as distinct runtime systems in Debian's Python world. So is it correct for both of them to attempt to provide the same command, when in most Python packages we're deliberately naming development tools to have Python 3 explicitly a separate runtime system? You will *not* find any upstream source code that will be using /usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all of them will be using /usr/bin/coverage (if they need the command line tool). Thinking that you will be able to patch all of them is both an illusion and a waste of time IMO. If we have update-alternatives, then it's very easy for a maintainer to choose which one of the 2 implementation it wants: Build-Depends: python-coverage Build-Conflicts: python3-coverage if you need /usr/bin/coverage to be python-coverage, or: Build-Depends: python3-coverage Build-Conflicts: python-coverage if you want /usr/bin/coverage to be the python3-coverage implementation. That's easy enough. Also, with priorities like I wished to set, python-coverage (eg: Python 2) was the preferred implementation. * If we're not going to have Python 2 and Python 3 packages attempt to provide the same command name, there doesn't seem much point using the Debian alternatives system. A symlink, as is already used in existing releases of the package, should be sufficient. There's no symlink in /usr/bin/coverage in the current package. * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in Debian for a Python-only development tool. While I agree in principles, there is, so far, no other package that claims this file. You can use apt-file search /usr/bin/coverage to check for this. The problem is that *upstream code* is using /usr/bin/coverage. So unless you explain this to upstream and have the issue fixed over there, and have it fixed in the pypi package, you cannot expect downstream code (users of python-coverage) to use anything else. Also, if there was another package that were using /usr/bin/coverage, it could also use the update-alternatives thing (if it's implementing the same thing, of course... otherwise we have a problem). This was the reason for renaming the binary ‘/usr/bin/python-coverage’ in every Debian release of the package so far. If you went into renaming the *source* package of python-coverage, then IMO you wasted your time. There's never a problem with source package name conflicts in Debian (I mean other than having things look nice, there's no technical problem), only with the resulting binaries and the files that they include. We both didn't want to hold the update of python-coverage which was really overdue: the last upload was from 2012-05, and version 3.6 (required for many packages) was released early last January. So I went ahead and sponsored the upload of python-coverage 3.7. I'm really glad to see this, and thanks to Thomas for agreeing to get Coverage 3.7 into Debian separately from this mostly-unrelated issue. :) Let's hope it passes the NEW queue fast. 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? Please let both Ben and I know your view. Likewise. (I'm subscribed to this forum, and AFAIK Thomas is also, so no need to Cc us on the discussion.) Agreed, also because that's the Debian list code of conduct to not do so unless requested. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525d08b4.2030...@debian.org
Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand z...@debian.org wrote: You will *not* find any upstream source code that will be using /usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all of them will be using /usr/bin/coverage (if they need the command line tool). Thinking that you will be able to patch all of them is both an illusion and a waste of time IMO. What sort of upstream source code would be using the /usr/bin wrapper at all? (I ask this question without prejudice; I can obviously imagine some ways this might happen, but I'm more interested in the actual existing use cases that you implied, not ones that only exist in my imagination) * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in Debian for a Python-only development tool. While I agree in principles, there is, so far, no other package that claims this file. You can use apt-file search /usr/bin/coverage to check for this. The problem is that *upstream code* is using /usr/bin/coverage. So unless you explain this to upstream and have the issue fixed over there, and have it fixed in the pypi package, you cannot expect downstream code (users of python-coverage) to use anything else. I think this is ultimately the problem of whichever package comes second, not python-coverage. (cf. other examples of name collisions, like ack/ack-grep) Also, if there was another package that were using /usr/bin/coverage, it could also use the update-alternatives thing (if it's implementing the same thing, of course... otherwise we have a problem). Presumably it would /not/ be implementing the same thing. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMcKhMShx87_d8dR=ouos+cfct_qhetx7hz+d6egli9dmbe...@mail.gmail.com
Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand z...@debian.org wrote: If we have update-alternatives, then it's very easy for a maintainer to choose which one of the 2 implementation it wants: Build-Depends: python-coverage Build-Conflicts: python3-coverage if you need /usr/bin/coverage to be python-coverage, or: Build-Depends: python3-coverage Build-Conflicts: python-coverage This looks wrong to me. If these programs are incompatible (i.e. provide different outputs), then this is a bug. Otherwise, there should be no need in Build-Conflicts. if you want /usr/bin/coverage to be the python3-coverage implementation. That's easy enough. Also, with priorities like I wished to set, python-coverage (eg: Python 2) was the preferred implementation. I think our goal is to switch as many modules to Python 3 as we can, so I don't see any point in giving python-coverage a bigger priority. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKimPHWx60HONdEtZ1EUEah98r7pQ4DgxmNc=DRhYJF06T4+=w...@mail.gmail.com
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 mity...@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
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131015110353.gb2...@jwilk.net
Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 3:04 PM, Jakub Wilk jw...@debian.org wrote:
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.
Right, I shouldn't have mentioned Sphinx here, as it is a very specific case.
As I understand it, python{2,3}-coverage are NOT compatible, and therefore
they should NOT use alternatives.
Can you please explain why they are incompatible for people who never
used them (like me)?
--
Dmitry Shachnev
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKimPHXN3NUYm9bSHOaSZHf=zdsnujt6h9gwt+ei3quk4e6...@mail.gmail.com
Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 3:14 PM, Dmitry Shachnev mity...@gmail.com wrote:
As I understand it, python{2,3}-coverage are NOT compatible, and therefore
they should NOT use alternatives.
Can you please explain why they are incompatible for people who never
used them (like me)?
I think I have figured it out myself: for example, coverage can use
versioned paths (like /usr/lib/python3/dist-packages/) in generated
reports. This is indeed an incompatibility.
--
Dmitry Shachnev
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKimPHVVWLJ3BRDeoSb_E5CoX99bi=smkg1dkzwirkxjblg...@mail.gmail.com
Re: Using update-alternatives for /usr/bin provided binaries
On 10/15/2013 07:04 PM, Jakub Wilk wrote: Apparently two (mostly orthogonal) problems have been squeezed into a single bug report: 1) Is the name /usr/bin/coverage appropriate? 2) Can the alternatives mechanism be used to switch between the two implementations of the coverage command line tool? Please let's focus on providing /usr/bin/coverage. I don't really care by what mechanism, as long as the unit tests are working, and Debian behaves like upstream coverage package from pypi. We can leave the implementation details for later. Even if only python-coverage (as opposed to the python3- version) was providing it, I'd be satisfied. On 10/15/2013 06:21 PM, Tristan Seligmann wrote: What sort of upstream source code would be using the /usr/bin wrapper at all? (I ask this question without prejudice; I can obviously imagine some ways this might happen, but I'm more interested in the actual existing use cases that you implied, not ones that only exist in my imagination) I'm not sure if you're talking about the *full path* bit or what. Upstream code (or at least, unit tests...) is calling coverage from the standard accessible $PATH. For example: zigo@ ~/os/heat/heat heat (debian/havana)# cat tox.ini | grep coverage python setup.py testr --coverage Nearly all OpenStack projects are using testrepository. All of them are using python-coverage. Many python modules are as well, and I had to patch some of them to avoid the problem (sorry, I can't remember which one right now...). I would like that it doesn't happen again, and also that our users (eg: developers trying to find out unit test coverage) can run the coverage tests without troubles. * The name ‘/usr/bin/coverage’ is, IMO, far too generic to claim in Debian for a Python-only development tool. While I agree in principles, there is, so far, no other package that claims this file. You can use apt-file search /usr/bin/coverage to check for this. The problem is that *upstream code* is using /usr/bin/coverage. So unless you explain this to upstream and have the issue fixed over there, and have it fixed in the pypi package, you cannot expect downstream code (users of python-coverage) to use anything else. I think this is ultimately the problem of whichever package comes second, not python-coverage. (cf. other examples of name collisions, like ack/ack-grep) Also, if there was another package that were using /usr/bin/coverage, it could also use the update-alternatives thing (if it's implementing the same thing, of course... otherwise we have a problem). Presumably it would /not/ be implementing the same thing. The thing is, we can bikeshed about what *may* happen *in the future*. Though right now, there's a problem which I would like to fix. And that is very easily fixed by providing /usr/bin/coverage, while ugly hacking (because that's what it is about) in all other upstream projects is a much, much harder task. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525d2b37.50...@debian.org
Re: Using update-alternatives for /usr/bin provided binaries
On 10/15/2013 07:01 PM, Dmitry Shachnev wrote: On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand z...@debian.org wrote: If we have update-alternatives, then it's very easy for a maintainer to choose which one of the 2 implementation it wants: Build-Depends: python-coverage Build-Conflicts: python3-coverage if you need /usr/bin/coverage to be python-coverage, or: Build-Depends: python3-coverage Build-Conflicts: python-coverage This looks wrong to me. If these programs are incompatible (i.e. provide different outputs), then this is a bug. Otherwise, there should be no need in Build-Conflicts. if you want /usr/bin/coverage to be the python3-coverage implementation. That's easy enough. Also, with priorities like I wished to set, python-coverage (eg: Python 2) was the preferred implementation. I think our goal is to switch as many modules to Python 3 as we can, so I don't see any point in giving python-coverage a bigger priority. -- Dmitry Shachnev Let's please forget about the above, and focus on python-coverage (eg: the Python 2.x implementation) to provide the /usr/bin/coverage support. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525d2bad.1090...@debian.org
Re: Using update-alternatives for /usr/bin provided binaries
* Dmitry Shachnev mity...@gmail.com, 2013-10-15, 15:14:
As I understand it, python{2,3}-coverage are NOT compatible, and therefore
they should NOT use alternatives.
Can you please explain why they are incompatible for people who never used
them (like me)?
$ echo 'print foo' foo.py
$ python-coverage -x foo.py
foo
With Python 3 implementation, you'll get SyntaxError.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131015113503.ga1...@jwilk.net
Re: Using update-alternatives for /usr/bin provided binaries
I'm sorry, I've been way too busy to help much with coverage; big thanks to Ben and Thomas for working on it. On Oct 15, 2013, at 05:19 PM, Thomas Goirand wrote: You will *not* find any upstream source code that will be using /usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all of them will be using /usr/bin/coverage (if they need the command line tool). Thinking that you will be able to patch all of them is both an illusion and a waste of time IMO. I don't think I've ever deliberately used the command line invocation of coverage. It's possible that something under-the-hood has done so, but I think most invoke coverage through Python. That means that *most* of coverage should be co-installable for both Python 2 and Python 3, which implies to me that the /usr/bin/whatever piece could be separate binary packages, and those could conflict. I'm not sure whether that would be more convenient than using alternatives, but it might be more correct. python-coverage could provide /usr/bin/coverage-2.7 while python3-coverage could provide /usr/bin/coverage-3.3, with symlinks provided by the appropriate -bin package. It's not like we haven't encountered similar problems before, e.g. nosetests, and AFAICT, we pretty much ad-hoc our way through it every time. `pythonX.Y -m package` is the safest way to invoke things, but people still want a nice convenient /usr/bin wrapper around that. I guess we still don't have a consistent way of doing this that everyone is happy with. -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131015152757.2fd9530c@anarchist
