The last couple releases of 8.x and 7.x have been rough for downstreams, what with breaking changes to comms and serializers changing on point releases of both supported branches.
Proposal
Perhaps a new repo, e.g. @jupyter-widgets/zoo could be created which made it easy to interactively test against "hot," unreleased versions of jupyter-widgets packages.
Design Ideas
In its simplest form, this could be a MyBinder-oriented repo which brought in and built the HEAD of the first-party repos in @jupyter-widgets, after installing any number of third-party widget packages.
A PR to this repo would be:
an entry in environment.yml (either in requirements or requirements/pip:)
a notebook in notebooks with some example usage
This would allow drive-by, interactive testing in binder, which is a far more reasonable ask than expecting all downstreams to check every point release. Checking this repo could become part of an issue template for doing a release.
In a more advanced form, a test folder could include some tests in various approaches (e.g. galata screen tests or functional, real-world-browser robotframework tests) which exercised the whole environment, gathered tracebacks, etc.
And even more advanced might be trying to build all of the above into a jupyterlite-based docs site.... but certainly can wait a tick there.
Problem
The last couple releases of 8.x and 7.x have been rough for downstreams, what with breaking changes to comms and serializers changing on point releases of both supported branches.
Proposal
Perhaps a new repo, e.g.
@jupyter-widgets/zoocould be created which made it easy to interactively test against "hot," unreleased versions ofjupyter-widgetspackages.Design Ideas
In its simplest form, this could be a MyBinder-oriented repo which brought in and built the
HEADof the first-party repos in@jupyter-widgets, after installing any number of third-party widget packages.A PR to this repo would be:
environment.yml(either inrequirementsorrequirements/pip:)notebookswith some example usageThis would allow drive-by, interactive testing in binder, which is a far more reasonable ask than expecting all downstreams to check every point release. Checking this repo could become part of an issue template for doing a release.
In a more advanced form, a
testfolder could include some tests in various approaches (e.g. galata screen tests or functional, real-world-browserrobotframeworktests) which exercised the whole environment, gathered tracebacks, etc.And even more advanced might be trying to build all of the above into a
jupyterlite-based docs site.... but certainly can wait a tick there.