Fix Compatibility Check for Prereleases

[blink1073]

References

Fixes #7241

The previous behavior is as follows:

• ^1.x is seen overlapping with ~2.0.0-x.y because 2.0.0-x.y is less than 2.0.0 in our logic
• ^1.x is not seen as overlapping with ~2.0.0 (verified locally)

This changes the logic to always strip our prelease info when doing the version compatibility check.

With these changes, the latest @jupyter-widgets/jupyterlab-manager cannot be installed into the alpha release:

Conflicting Dependencies:
JupyterLab                        Extension              Package
>=2.0.0-alpha.0 <2.1.0            >=1.2.0 <2.0.0         @jupyterlab/application
>=4.0.0-alpha.0 <4.1.0            >=3.2.0 <4.0.0         @jupyterlab/coreutils
>=2.0.0-alpha.0 <2.1.0            >=1.2.0 <2.0.0         @jupyterlab/notebook
>=2.0.0-alpha.0 <2.1.0            >=1.2.0 <2.0.0         @jupyterlab/rendermime
>=2.0.0-alpha.0 <2.1.0            >=1.5.0 <2.0.0         @jupyterlab/rendermime-interfaces
>=5.0.0-alpha.0 <5.1.0            >=4.2.0 <5.0.0         @jupyterlab/services

However, an extension that declares a dependency on any prerelease version or final version of JupyterLab can be installed (tested with a local extension depending on "@jupyterlab/application": "^2.0.0-rc.0" and "@jupyterlab/application": "^2.0.0").

Code changes

Compare against final releases in the version compatibility check.

User-facing changes

Users can no longer install incompatible extensions during the prerelease cycle.

Backwards-incompatible changes

Incompatible extensions can no longer be installed.

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[jasongrout]

With these changes, the latest @jupyter-widgets/jupyterlab-manager cannot be installed into the alpha release:

That's too bad. So this comment isn't true anymore?

https://github.com/jupyterlab/jupyterlab/pull/7723/files#diff-f889c27ebc01f0305bbef39cfd65085bR1985-R1987

[blink1073]

The comment is still true. The extension author can just specify the new final version or any prerelease version and it will work.

[jasongrout]

Can we make this behavior an option in the function? As a standalone function, it's surprising that it ignores the prerelease option on just one end of one of the ranges. Would we get the same end result if we had an "increment prerelease" flag as an argument, and then just did this logic on both ends of both ranges?

[blink1073]

Sure, we can make this behavior optional in the standalone function. It only has an effect on the lower end of the range, since ~2.0.0-b1 gets interpreted originally as 2.0.0-b1 <= x < 2.1.0 and converted to 2.0.0 <= x < 2.1.0. By doing it on the lower end of the first argument, we are saying that we don't do compatibility checks within our own prerelease cycle only.

[jasongrout]

Thanks!