Fix table display wrapper #103
Conversation
|
Can you bump the version number so we can release right away after this PR? |
|
The version is also hardcoded in beakerx_tabledisplay/beakerx_tabledisplay/_version.py |
| from IPython.display import display_html | ||
| from IPython.display import display |
There was a problem hiding this comment.
Not for this PR, but I realized this file is misspelled - we should fix that.
| "version": "2.4.3", | ||
| "version": "2.4.4", |
There was a problem hiding this comment.
Versioning ergonomics tangent:
This would be for the front-end which I don't think is strictly required here for this patch? If this is to keep the two versions of the widget pinned together, that seems preferred to me too. Is there a versioning mechanism that other Jupyter projects use in these scenarios, where they can bump both versions without updating the respective lock/requirements files individually?
There was a problem hiding this comment.
Most Jupyter packages keep frontend and backend versions in sync. We use only the version number in the package.json file for both. The Python version number is generated at release-time.
There was a problem hiding this comment.
We could technically publish of new version of the Python package of beakerx_tabledisplay without bumping the frontend version indeed. There is a loose requirement for the front-end package, the Python package will work with any front-end extension as long as the widget models are compatible (which is the case in this PR).
No description provided.