Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump controls version to 1.2.0 #2017

Merged
merged 8 commits into from
Mar 29, 2018
Merged

Conversation

jasongrout
Copy link
Member

We do this now so we can test the backwards compatibility before the release.

@jasongrout jasongrout added this to the 7.2 milestone Mar 23, 2018
@jasongrout
Copy link
Member Author

jasongrout commented Mar 23, 2018

I just changed the logic of the JupyterLab manager in efea844 - if a specific module version is requested (not a semver range), then it defaults to the ^ semver range to get a compatible module.

This would fix the problem we see in #2006, for example. If someone wants to insist on a specific version, they should use the range specifier =1.2.3.

@SylvainCorlay - thoughts? This does change the behavior for plain versions, but I think it makes the behavior more intuitive and better addresses the various places we need version numbers. I think it also probably makes sense to make the same change in the html manager?

@jasongrout
Copy link
Member Author

ping @SylvainCorlay

@vidartf
Copy link
Member

vidartf commented Mar 28, 2018

For future reference it would be nice if this had some tests outlining basic expected behavior. A side effect of this is that it is impossible for packages to lock one version to another (or that would require a one-element range).

@jasongrout
Copy link
Member Author

A side effect of this is that it is impossible for packages to lock one version to another (or that would require a one-element range).

Yes, it would require a semver range =1.2.3

@jasongrout
Copy link
Member Author

(If this is too big of a change for a minor release, we can probably hold off on something like this until 8.0)

…ontrols packages.

This resolves the backwards-incompatibility issues for other libraries with applying this logic to all modules, but still fixes jupyter-widgets#2006.
@jasongrout
Copy link
Member Author

(If this is too big of a change for a minor release, we can probably hold off on something like this until 8.0)

Since this is technically a backwards-incompatible change in general, I special-cased the changes to just the Jupyter-widgets/[base,controls] packages. We can take up the issue of making the more general change for 8.0 later.

@jasongrout
Copy link
Member Author

For future reference it would be nice if this had some tests outlining basic expected behavior. A side effect of this is that it is impossible for packages to lock one version to another (or that would require a one-element range).

The last commits roll back the behavior for general packages.

@jasongrout jasongrout merged commit 375832c into jupyter-widgets:master Mar 29, 2018
@jasongrout jasongrout mentioned this pull request Mar 30, 2018
10 tasks
@nscozzaro
Copy link

nscozzaro commented May 7, 2020

@jasongrout I'm trying to get ipywidgets to work in my JupyterLab extension but I'm getting an error related to this, which I don't understand: "Error: Module @jupyter-widgets/base, semver range ^1.2.0 is not registered as a widget module", and many other similar errors.

What I did was to copy all of the code from the jupyterlab-manager extension into my extension, changed the INotebookTracker to my modified INotebookTracker, and now I'm getting this error. Would very much appreciate any guidance as to how I might solve this problem. Thanks

image

image

These are the versions I'm using in package.json:
image

@lock lock bot added the resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Jun 24, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Jun 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants