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

Fix Compatibility Check for Prereleases #7723

Merged
merged 5 commits into from Jan 7, 2020
Merged
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
10 changes: 8 additions & 2 deletions jupyterlab/commands.py
Expand Up @@ -1186,7 +1186,7 @@ def _populate_staging(self, name=None, version=None, static_url=None,
json.dump(data, fid, indent=4)

# copy known-good yarn.lock if missing
lock_path = pjoin(staging, 'yarn.lock')
lock_path = pjoin(staging, 'yarn.lock')
lock_template = pjoin(HERE, 'staging', 'yarn.lock')
if self.registry != YARN_DEFAULT_REGISTRY: # Replace on the fly the yarn repository see #3658
with open(lock_template, encoding='utf-8') as f:
Expand Down Expand Up @@ -1774,7 +1774,7 @@ def _node_check(logger):

def _yarn_config(logger):
"""Get the yarn configuration.

Returns
-------
{"yarn config": dict, "npm config": dict} if unsuccessfull the subdictionary are empty
Expand Down Expand Up @@ -1982,6 +1982,12 @@ def _compare_ranges(spec1, spec2):
y1 = r2.set[0][0].semver
y2 = r2.set[0][-1].semver

# Drop prereleases in comparisons to allow extension authors
# to not have to update their versions for each
# Jupyterlab prerelease version.
if x1.prerelease:
x1 = x1.inc('patch')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


o1 = r1.set[0][0].operator
o2 = r2.set[0][0].operator

Expand Down