-
Notifications
You must be signed in to change notification settings - Fork 79
Implement simple versions and ranges #305
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
Conversation
For reference, here are the stats based on master prior to the
|
7988f72
to
f4295c2
Compare
And here's the results from this pull request:
We're looking at about 2,000 versions affected either because their package version is not good, or because they depend on package versions that are no good. This is more significant than I was expecting; I'll need to dig in a little more to see exactly why so many versions are affected. |
In the latest commit I've taken some actions to fix ranges that could be valid according to our simple range spec, but which currently aren't converted. Some examples:
With this change, the new stats are:
Many of the new failed versions have nothing to do with prerelease identifiers but rather to do with ranges we should never have accepted, like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just a few places that can be cleaned up.
In 0bfe903 I added support for trimming prerelease identifiers from dependency ranges when parsing in lenient mode. The new results with this change:
There are 83 packages that have moved from 'totally succeeded' to 'partially succeeded' and 23 packages that are now failing entirely. There are about 400 more package versions that are affected by the |
@@ -83,14 +84,17 @@ exampleFailures = PackageFailures $ Map.fromFoldable | |||
exampleStats :: Stats.Stats | |||
exampleStats = Stats.errorStats mockStats | |||
where | |||
unsafeFromRight :: forall e a. Either e a -> a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we put this in Registry.Prelude
? I think we define this in quite a few places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm down to do that, but I'd like to do it in a followup PR to keep this one from touching many more files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
Fixes #43 by implementing new
Version
andRange
types with parsers according to the spec described there.In 5b3da44 I added a new
Version.purs
file that implements aVersion
type along with a parser and printer, enforcing that versions have the formX.Y.Z
where each place is a non-negative integer. This file also implements aRange
type with a parser and printer, enforcing that ranges have the form>=X.Y.Z <X.Y.Z
. I also added tests to ensure this is working properly.In 4a48ff5 I then replaced the existing
SemVer
andRange
types with the new types throughout the application. This allows us to remove almost all of theSemVer
module and the accompanying tests. We retainparseRange
since we use that in the legacy import tool to convert ranges.In f4295c2 I introduced 'strict' vs. 'lenient' parsers for the
Version
andRange
types, as sometimes we are working with user input we expect to be valid (ie. when a user uploads a new package) and sometimes we expect the input to be invalid (ie. when converting from an existing Bowerfile). I've also added araw
field to both types as we need to preserve the input in the case of the lenient parser; for the strict parser the input is identical to the printing functions. One day we can probably remove the lenient mode, but we need it for the time being.In d3517d1 I went further by doing more work to convert ranges that are technically incorrect but which could be converted into correct ranges. This saves us a lot of versions that would otherwise be kicked out of the registry due to an incorrect format. For example, the range
1.0.0
is invalid but can be rewritten to>=1.0.0 <1.0.1
.This change affects several hundred package versions, but the vast majority of those are not due to removing the prerelease identifiers. Instead, it's because we previously accepted many ranges that we shouldn't have, like
*
or>=1.0.0
or>1.0.0 <2.0.0 || >5.0.0 <6.0.0
.However, 237 package versions will be dropped due to using a prerelease identifier in their version, and 1 package version will be dropped due to using build metadata (out of ~13,000 total). The vast majority of these predate the use of package sets and won't affect typical user -- for example, many of them are in the PureScript libraries that were part of the 0.9 release back in 2016.
For this reason I feel comfortable with these versions being dropped and us sticking with the new strict simple ranges.
A topic for discussion: What if we just stripped all prerelease identifiers while cleaning version ranges in the legacy import tool? For example, a version range
>=1.0.0-beta <2.0.0
would just be rewritten to>=1.0.0 <2.0.0
. We'd still remove package versions that include a prerelease identifier, but we could fix packages that depend on those packages.