[TIP] Disable keyboard shortcuts in html coverage reports?
ned at nedbatchelder.com
Tue Mar 4 18:08:28 PST 2014
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
>> 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
>> It seems like the options to fix this are:
>> - Make coverage use it's locally bundled files always. I.e.- _never_
> 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.
More information about the testing-in-python