[TIP] Disable keyboard shortcuts in html coverage reports?

[Ned Batchelder]

On 3/4/14 8:39 PM, Ben Finney wrote:
> Thomi Richards <thomi.richards at canonical.com> writes:
>
>> As discussed on IRC, the root problem here twofold:
>>
>>     1. coverage, when copying static files to the html report dir will look
>>     in the system path (/usr/share/javascript) for the files it wants, and will
>>     prefer those files over the ones it bundles locally.
> Right. In an OS with updates for packages, this is the preferred
> behaviour: A new library (like ‘jquery.hotkeys.js’) should be
> automatically used, instead of needing explicit upgrade in every package
> that uses it.
>
>>     2. The jquery-hotkeys JS files that are shipped in trusty have changed,
>>     and are no longer compatible with coverage.
> That's a problem in communication, IMO. If the changes in the library
> are backward-incompatible, the library developer is not properly
> communicating these changes to dependent developers.
I'm not sure why we think a "library developer" like this one will 
communicate changes to dependent developers.  Notice that his version 
management scheme was to change "0.8" to "0.8+"!  Notice also that 
jQuery plugins don't have an actual distribution mechanism, you are 
meant to find them on github and copy them into your project.  I was 
opposed to imposing some kind of fictional discipline where none 
existed, but went along with the package maintainer's strong preference 
anyway.
>
>> It seems like the options to fix this are:
>>
>>     - Make coverage use it's locally bundled files always. I.e.- _never_
>>     look in /usr/share/javascript
> This was deliberately added to behave properly on a package-managed OS
> (such as Debian and derivatives), so I would expect that behaviour to
> remain, for all the third-party JS libraries.
>
>>     - Try and roll back the jquery.hotkeys changes in trusty.
> The missing option, and the preferable one IMO, is:
>
> * Find out what changes in the library broke Coverage; fix Coverage so
>    it works with the latest published library.
>
>> Let me know which solution you prefer, and I'll see if I can fix things up.
> I'm aware that many JS developers don't seem to care much about breaking
> existing dependent code with new updates, but I don't think that is a
> reason to accept the status quo.
It seems to me that we treated jquery.hotkeys as if it were a properly 
maintained and distributed library.  If we are aware that the developer 
doesn't care to treat it as one, perhaps we shouldn't either?  I'm all 
for not accepting the status quo, but in this case we didn't try to 
change it, we just buried our heads in the sand. And now apparently the 
recommendation of how to fix this isn't to contact the library author, 
but for me to somehow figure out what broke, and to change coverage.py 
to accommodate it.  How is that fixing the status quo?

The right thing to do would be to contact the authors and get them to 
change their stance toward their own software.  Once they did, then we 
could stop vendoring it.

--Ned.
>