[TIP] Disable keyboard shortcuts in html coverage reports?

[Daniel Staple -X (dastaple - BSKYB at Cisco)]

> From: testing-in-python-bounces at lists.idyll.org [mailto:testing-in-python-
> bounces at lists.idyll.org] On Behalf Of Ned Batchelder
> Sent: 03 March 2014 11:38
> To: Ben Finney; testing-in-python at lists.idyll.org
> Subject: Re: [TIP] Disable keyboard shortcuts in html coverage reports?
> 
> On 3/2/14 10:32 PM, Ben Finney wrote:
> > Ned Batchelder <ned at nedbatchelder.com> writes:
> >
> >> On 3/2/14 4:37 PM, Thomi Richards wrote:
> >>> I've managed to track the problem down to the 'jquery.hotkeys.js'
> >>> file. In Precise this is version '0.8', in trusty it's '0.8+'. […]
> >> This sounds like the problem is not in coverage.py at all, but in the
> >> jquery.hotkeys.js file it depends on? Perhaps Trusty shouldn't take a
> >> new version, or you can get in touch with the developer?
> > Ideally, you as the author of a library depending on
> > “jquery.hotkeys.js”, should communicate with the author of that
> > library to make sure newer versions continue to work with your dependent
> code.
> >
> > If there are changes in the library (and changes so small they
> > apparently don't warrant an increase in the version string) that cause
> > dependent code to break, the library code and/or the dependent code
> > needs to be fixed.
> >
> > Do you agree?
> >
> Actually, as you know, I was in favor of having my own copy of these tiny
> jQuery libraries that I needed to make coverage.py work. You were in favor
> of applying the Debian philosophy of making everything a separate library, no
> matter how finely sliced.  The theory was that I could automatically get fixes.
> Now I've automatically gotten bugs.  I had a package that worked.  Debian
> has a package that does not.  Now I have to chase down the author?  :(
> 
> Who made the decision to upgrade the package in Debian?
> 
> --Ned.

This may sound ludicrous but:
* Packages have dependents in machine readable formats
* Dependents can have automatic test suites. I'd be surprised if coverage.py didn't.
* This could be run as automated testing with Travis or Jenkins.
* There are a number of free open source test infrastructure providers.

I am aware it is much more complicated than this and probably requires time to set up, but it wouldn't be unreasonable to suggest setting up a hook to trigger the coverage.py tests in Debian when the packages it depends on change. Perhaps when slicing so thinly - something like this is what would protect the packages from breaking like this.

Danny