Re: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool
Thomas Goirand writes: > On 10/16/2013 07:32 AM, Ben Finney wrote: > > Patching upstream's assumptions of command names is a feature of the > > landscape for Debian packagers. I don't consider that a reason to > > presume ‘/usr/bin/coverage’ on Debian should refer to a > > Python-specific tool. > > I'm not denying the fact it's possible to do what you say. I'm saying > it's too much effort compared to providing /usr/bin/coverage in > Debian. Yes, providing ‘/usr/bin/coverage’ would be a small amount of effort. That is less important than the question: is it a good idea to do it? Many bad ideas would be a small amount of effort to implement. So, comparing amounts of implementation effort does not make a compelling argument. > You are simply ignoring this point of my argumentation, which is the > most important part. If that's the most important part, I fear you don't have a compelling case for this request. > You have also ignore the point where I say that there's currently no > conflict, so it doesn't mater. The best case is if *no* language-specific programming tool ever grabs that over-broad name in Debian. I can say with confidence that this is exactly why the program has been deliberately installed with the name ‘/usr/bin/python-coverage’ in Debian for every release of the ‘python-coverage’ package to date. It is a positive reason that remains relevant. > Could you please reply to both points? Those are my responses, thanks for pursuing them. I'm glad we discussed this. I haven't seen a convincing argument that overrides the consensus here that a Python-specific programming tool should not claim the broad name ‘/usr/bin/coverage’ in Debian. -- \ “The greater the artist, the greater the doubt; perfect | `\ confidence is granted to the less talented as a consolation | _o__) prize.” —Robert Hughes | 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/7wa9i9kaez@benfinney.id.au
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: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool
Thomas Goirand writes: > 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. If some upstream code is making many invocations of one command with a hard-coded name, that's an argument to work with upstream and ask them to parameterise their code better (and patch it until they do), so OS packagers can easily alter the invocations to match OS-specific command locations. This effort is part of maintaining software in Debian: working with upstream to convince them to make their code work well in a universal operating system. In which vein, you've motivated me to raise an issue for this problem upstream https://bitbucket.org/ned/coveragepy/issue/272/> with the Python Coverage library maintainer, to argue for addressing the cause of the problem. Thanks! -- \ “… one of the main causes of the fall of the Roman Empire was | `\that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs.” —Robert Firth | 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/7whachkay6.fsf...@benfinney.id.au
Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand 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: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool
On 10/16/2013 07:32 AM, Ben Finney wrote: >> Nearly all OpenStack projects are using testrepository. All of them >> are using python-coverage. > > That sounds like an excellent central point to make the command name > parameterisable: fix it in one place to match the Debian > ‘python-coverage’ package, and all OpenStack packages can benefit from > that. > > Note that I don't know whether that would work, but it's one option that > seems available. Unfortunately, that's not the case. >> 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. > > Patching upstream's assumptions of command names is a feature of the > landscape for Debian packagers. I don't consider that a reason to > presume ‘/usr/bin/coverage’ on Debian should refer to a Python-specific > tool. I'm not denying the fact it's possible to do what you say. I'm saying it's too much effort compared to providing /usr/bin/coverage in Debian. You are simply ignoring this point of my argumentation, which is the most important part. You have also ignore the point where I say that there's currently no conflict, so it doesn't mater. In the future *IF* there is one, then we may fix, but in the meanwhile, there is no problem at all. So why should we bother? Could you please reply to both points? Thomas P.S: Also, please keep 726...@bugs.debian.org as CC. -- 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/525e166d.3020...@debian.org
Re: Packaging AngularJS application as part of the python twisted application
On Wed, Oct 16, 2013 at 7:54 AM, Ben Finney wrote: > I think we're going to have to (as the Debian Python community? as the > broader Debian maintainer community?) come up with a unified approach to > dealing with the rapidly increasing tendency for upstream releases > bundling doing this. Upstream bundling happens in too many different ways to deal with that in any way other than to push back every time an upstream wants to add yet more embedded code copies[1] to Debian. Tell them to do things in a sane way otherwise we can't add their stuff into Debian. Tell them to read the upstream guide (and update it if need be). Tell them to release proper source tarballs that are exactly the same as their VCS. Tell them to not commit generated files to their VCS. Tell them to never include copies of their dependencies in their VCS. Tell them to switch from systems without sane repository and dependency systems (such as Android, MacOS X and Windows) to GNU/Linux distributions like Debian. Tell them to think about sysadmins before themselves. http://wiki.debian.org/EmbeddedCodeCopies http://wiki.debian.org/UpstreamGuide -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6ehwzs8n1ecab4t2cdkcbupm+uabkok-n2lrd0ayfr...@mail.gmail.com
Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool (was: Using update-alternatives for /usr/bin provided binaries)
Thomas Goirand writes: > 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? > > Please let's focus on providing /usr/bin/coverage. I'm not convinced Debian's ‘python-coverage’ should arrogate the name ‘/usr/bin/coverage’ to itself. We all seem to agree; your position seems to be that a decision made upstream should overrule that. > 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. As with a lot of other software, Debian packages can patch hard-coded command name invocations to match the command names in Debian. I've had to do this with other works; I've even had productive discussions with upstream to convince them not to hard-code the command names everywhere and allow parameterised command names to make packaging easier. > Nearly all OpenStack projects are using testrepository. All of them > are using python-coverage. That sounds like an excellent central point to make the command name parameterisable: fix it in one place to match the Debian ‘python-coverage’ package, and all OpenStack packages can benefit from that. Note that I don't know whether that would work, but it's one option that seems available. > 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. Patching upstream's assumptions of command names is a feature of the landscape for Debian packagers. I don't consider that a reason to presume ‘/usr/bin/coverage’ on Debian should refer to a Python-specific tool. -- \ “Why doesn't Python warn that it's not 100% perfect? Are people | `\ just supposed to “know” this, magically?” —Mitya Sirenef, | _o__) comp.lang.python, 2012-12-27 | 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/7w38o2kt3r.fsf...@benfinney.id.au
Joining PMPT
Hi all, I'm hoping to package a couple of python modules needed by a web app that I'm looking to run on Debian: - ntplib - python-iptables I'm pretty new to Python packaging, so I'd appreciate some review once they're ready. And what better way to get that than to join the relevant team? :) I submitted a request to join on Alioth (username: diocles), but I notice that I could actually commit to SVN already. Still, it's nice to say hello. -- Tim Retout signature.asc Description: This is a digitally signed message part
Packaging AngularJS application as part of the python twisted application
Dear mentors, python hackers, Debian developers I'm maintaining buildbot[1] packages for quite some time. While current packaging of this application is not that hard, the upcoming 0.9 release includes a new web interface organized as python module called 'buildbot_www'. This module is in fact an AngularJS web application that build-depends on nodejs and npm. The current procedure of release this module implies following steps: 1) git clone git://github.com/buildbot/buildbot 2) git checkout -tb nine origin/nine 3) cd www 4) python setup.py sdist The last command performs the actual building of the python module: 1) npm/bower downloads necessary Javascript libraries (download 152Mb of js libraries in .tar.gz) 2) the main (minified/uglified) Javascript file is generated 3) other js/css resources are generated using tools like coffeescript and less 4) html files are generated as well In the end these files are included in the resulting python module tarball. It is totally valid python sdist tarball that can be packaged using ordinary rules of Python packaging. But according to the Debian policy this tarball cannot be considered as a source tarball since it contains generated code, minified js/css etc. I have raised the discussion on the upstream mailing list[2]. Their intention is understandable: current approach allows python developers to work on python code whithout bothering with nodejs/npm while frontend devs could easily hack web iterface without need of python backend. Thanks to the conversation on IRC with Ben Finney, I've detected some potential ideas that should be addressed upstream: 1) provide valid (from Debian's PoV) source tarball for buildbot_www Python module 2) have separate source tarball with bundled javascript dependencies that can be handled by DebSrc 3.0 format as additional upstream tarball; also make possible to use this external tarball in the build process without need of internet connection, It would be possible to replace external js deps with ones already packaged for Debian as well, for example. What steps can be done in such case? What can be done better? Please share your thoughts. I believe, there would appear more similar projects in the future, so the conversation should be useful for a lot more people. Thanks. [1]: http://buildbot.net [2]: http://thread.gmane.org/gmane.comp.python.buildbot.devel/9744 -- Best regards, Andriy Senkovych -- 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/CAMS_SFKWukZ4Kzekcxg29z=s6jxfwyaquyl8pwn9ceho_aq...@mail.gmail.com
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/ 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 ` 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
Re: Using update-alternatives for /usr/bin provided binaries
* Dmitry Shachnev , 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
On 10/15/2013 07:01 PM, Dmitry Shachnev wrote: > On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand 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
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 ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems
* Thomas Goirand , 2013-10-15, 01:47: Unless something changed recently, Debian buildds don't block Internet access. :( I've read multiple times that they do. Could you show a build log where something is downloaded? The only thing I found[0] is a bit old, but here you go: https://buildd.debian.org/status/fetch.php?pkg=python-ethtool&arch=i386&ver=0.7-1&stamp=1340805337 http://bugs.debian.org/683174 [0] Unfortunately Google doesn't seem to index Debian build logs. :( Perhaps someone wants to implement buildlogsearch.debian.net? -- 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/20131015112525.ga...@jwilk.net
Re: Using update-alternatives for /usr/bin provided binaries
On Tue, Oct 15, 2013 at 3:14 PM, Dmitry Shachnev 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 Tue, Oct 15, 2013 at 3:04 PM, Jakub Wilk 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
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 , 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 1:19 PM, Thomas Goirand 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
On Tue, Oct 15, 2013 at 11:19 AM, 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. 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 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