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 ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems
* Thomas Goirand z...@debian.org, 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-ethtoolarch=i386ver=0.7-1stamp=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 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
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
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 dioc...@debian.org signature.asc Description: This is a digitally signed message part
Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool (was: Using update-alternatives for /usr/bin provided binaries)
Thomas Goirand z...@debian.org 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
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
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
