Semver matching #127

GregBowyer · 2020-01-30T19:44:11Z

This is a little WIP, as we / I need to add unit and integration tests for this.

In reworking #123 a little, to allow for aliases to be presented in the "root" raze crate and to avoid a problem with crates presenting multiple versions of aliases I added in basic support for using the semver library to do matches for alias determination.

It occured to me, that rather than just use semver in that one specific place we should expose the richness of the semver objects into raze more generally. As such this commit exposes semver to raze and allows it to use semver for both version details and in matching configuration settings.

Semver Matching

Raze settings come in the form of a TOML section like so

[raze.crates.some-crate.'1.2.3']
some_new_setting = true

Where the version number (in the above example 1.2.3) is a literal, hardcoded
value.

This works but is a little inflexible for dependencies, especially
dependencies that are transiant and update a lot (for instance syn).

Since Cargo follows Semver we can use this fact, along with the richness of
the exported and serialisable semver::Version types to perform section
matching with Semver in the same fashion as Cargo itself.

This means that the above example can be written with semver expressions, for
example it can be written as:

[raze.crates.some-crate.'1.2.*']
some_new_setting = true

[raze.crates.some-crate.'~1.2.3']
some_new_setting = true

[raze.crates.some-crate.'^1.2.3']
some_new_setting = true

[raze.crates.some-crate.'=1.6.6']
some_new_setting = true

Note: Bare versions follow the semantics as if they had specified a ^,
which is in keeping with Cargo semver semantics but is distinct from previous
behaviour of raze (in which these would be interpreted as exacting or =).

This is deliberate as we should aim to mirror the semantics of cargo as much as
possible to avoid confusion.

We presently do not allow for multiple matches in raze settings, this is
intentional and is presented to the end user as an error.

acmcarther · 2020-01-31T02:20:48Z

This feature looks good to me, and is more user friendly than the original implementation. I originally justified my laziness here with the assumption that overrides/settings would need to be tweaked between versions, but in practice I haven't seen this be true and it's a nuisance to manually bump these versions.

Can you rebase this off master now that #121 is merged?

acmcarther · 2020-04-01T02:01:36Z

I'm not sure if this is waiting on me, or is stuck on something else.

Is this ready to submit? Looks like it needs a rebase.

GregBowyer · 2020-04-02T18:03:32Z

I was going to write some unit tests but had not got around to it

impl/src/planning.rs

UebelAndre · 2020-09-09T14:54:44Z

@GregBowyer Hey, is this still relatively close to being done?

Additionally, would this allow for me to also specify the following?

[raze.crates.some-crate.'*']
some_new_setting = true

GregBowyer · 2020-09-09T16:20:46Z

It would / it does. Personally I always do that with a range (sometimes crates remove / alter things a glob can mess up), but nothing is stopping that usage. Its waiting on me not being lazy :S I will try to find some time this week.

…

On Wed, Sep 9, 2020, at 7:55 AM, UebelAndre wrote: @GregBowyer <https://github.com/GregBowyer> Hey, is this still relatively close to being done? Additionally, would this allow for me to also specify the following? [raze.crates.some-crate.'*'] some_new_setting = true — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#127 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6X3YWY24ITA7S6O73QQ3SE6JMNANCNFSM4KN3Y2QA>.

UebelAndre · 2020-09-09T16:26:33Z

@GregBowyer Thanks! Really looking forward to this change getting in 😄

UebelAndre · 2020-09-15T00:37:40Z

@GregBowyer Hey, just a friendly poke? Do you think you'll have some time this week for this pull request? 😅

GregBowyer · 2020-10-30T21:41:58Z

@UebelAndre its my top thing today (sorry took a while). Since you have built out an awesome test framework I can make good headway with ... some actual tests :P

GregBowyer · 2020-10-30T23:17:48Z

Ok unit test pushed so we can take a review

dfreese

LGTM after a rebase and some very picky nits.

impl/src/planning.rs

dfreese · 2020-11-06T23:45:32Z

Thanks for putting this together! Assuming CI passes, I'll go ahead and release this under 0.7.0

dfreese · 2020-11-06T23:52:19Z

Thanks for putting this together! Assuming CI passes, I'll go ahead and release this under 0.7.0

The command "if [ -n "$(git status --porcelain)" ]; then 
  echo '/examples is out of date. Please run `./smoke-test.sh` locally and commit the changes' >&2
  exit 1
fi" exited with 0.

Looks like the examples need to be updated.

GregBowyer · 2020-11-07T00:06:59Z

Just git add examples/vendored?

UebelAndre · 2020-11-07T00:10:13Z

The vendored source should be ignored

git stage examples should get you the relevant new things I think

GregBowyer · 2020-11-07T00:12:40Z

Humm after running smoke-test then I get nothing for examples

UebelAndre · 2020-11-07T00:15:56Z

Oh, that's not the error.

cargo-raze appears to have failed to build tests

GregBowyer · 2020-11-07T00:44:39Z

Weird ... pushed the fix

Raze settings come in the form of a [TOML] section like so ```toml [raze.crates.some-crate.'1.2.3'] some_new_setting = True ``` Where the version number (in the above example `1.2.3`) is a literal, hardcoded value. This works but is a little inflexible for dependencies, _especially_ dependencies that are transiant and update a lot (for instance `syn`). Since Cargo follows [Semver] we can use this fact, along with the richness of the exported and serialisable `semver::Version` types to perform section matching with [Semver] in the same fashion as Cargo itself. This means that the above example can be written with semver expressions, for example it can be written as: ```toml [raze.crates.some-crate.'1.2.*'] some_new_setting = True [raze.crates.some-crate.'~1.2.3'] some_new_setting = True [raze.crates.some-crate.'^1.2.3'] some_new_setting = True [raze.crates.some-crate.'=1.6.6'] some_new_setting = True ``` _Note_: Bare versions follow the semantics _as if they had_ specified a `^`, which is in keeping with [Cargo semver semantics] but is distinct from previous behaviour of raze (in which these would be interpreted as exacting or `=`). This is deliberate as we should aim to mirror the semantics of cargo as much as possible to avoid confusion. We presently do not allow for multiple matches in raze settings, this is intentional and is presented to the end user as an error. [TOML]: https://github.com/toml-lang/toml [Semver]: https://semver.org/spec/v2.0.0.html [Cargo semver semantics]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-cratesio

dfreese · 2020-11-07T01:46:19Z

Released in 0.7.0

UebelAndre · 2020-11-07T02:19:54Z

@dfreese how did you deploy? Isn't there normally a commit associated with a deploy?

dfreese · 2020-11-07T04:27:10Z

@dfreese how did you deploy? Isn't there normally a commit associated with a deploy?

1b7e178. Forgot to push the commit.

GregBowyer force-pushed the semver-matching branch from cd55849 to 1354598 Compare January 30, 2020 22:45

GregBowyer mentioned this pull request Feb 28, 2020

Tracking crates with exotic build.rs #41

Open

zoidyzoidzoid mentioned this pull request Feb 28, 2020

We need to generate some build.rs's acmcarther/cargo-raze-crater#5

Open

GregBowyer force-pushed the semver-matching branch 2 times, most recently from a7c9f59 to a578c09 Compare April 30, 2020 02:26

GregBowyer force-pushed the semver-matching branch 2 times, most recently from b52ca19 to cc96241 Compare July 20, 2020 19:05

GregBowyer mentioned this pull request Jul 21, 2020

Allow for aliases at the top level #187

Closed

dfreese reviewed Jul 24, 2020

View reviewed changes

impl/src/planning.rs Outdated Show resolved Hide resolved

GregBowyer force-pushed the semver-matching branch from cc96241 to be0df8d Compare October 30, 2020 20:44

GregBowyer mentioned this pull request Oct 30, 2020

[Lint] Change inline test texts to use indoc! #272

Merged

GregBowyer force-pushed the semver-matching branch from be0df8d to 2bd28e8 Compare October 30, 2020 23:15

dfreese approved these changes Nov 5, 2020

View reviewed changes

impl/src/planning.rs Outdated Show resolved Hide resolved

impl/src/planning.rs Show resolved Hide resolved

dfreese mentioned this pull request Nov 5, 2020

Accept [package.metadata.raze], superseding [raze] #274

Merged

GregBowyer force-pushed the semver-matching branch from 2bd28e8 to b306f63 Compare November 6, 2020 23:31

dfreese approved these changes Nov 6, 2020

View reviewed changes

GregBowyer force-pushed the semver-matching branch from b306f63 to 5e46892 Compare November 7, 2020 00:44

GregBowyer mentioned this pull request Nov 7, 2020

Rework planning to be based off the resolve tree and not directly pkgs #282

Closed

dfreese approved these changes Nov 7, 2020

View reviewed changes

GregBowyer force-pushed the semver-matching branch from 5e46892 to 0e1af3d Compare November 7, 2020 01:01

dfreese approved these changes Nov 7, 2020

View reviewed changes

dfreese merged commit 9e82b65 into google:master Nov 7, 2020

GregBowyer deleted the semver-matching branch November 7, 2020 01:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Semver matching #127

Semver matching #127

GregBowyer commented Jan 30, 2020 •

edited

Loading

acmcarther commented Jan 31, 2020

acmcarther commented Apr 1, 2020

GregBowyer commented Apr 2, 2020

UebelAndre commented Sep 9, 2020

GregBowyer commented Sep 9, 2020 via email

UebelAndre commented Sep 9, 2020

UebelAndre commented Sep 15, 2020

GregBowyer commented Oct 30, 2020

GregBowyer commented Oct 30, 2020

dfreese left a comment

dfreese commented Nov 6, 2020

dfreese commented Nov 6, 2020

GregBowyer commented Nov 7, 2020

UebelAndre commented Nov 7, 2020

GregBowyer commented Nov 7, 2020

UebelAndre commented Nov 7, 2020

GregBowyer commented Nov 7, 2020

dfreese commented Nov 7, 2020

UebelAndre commented Nov 7, 2020

dfreese commented Nov 7, 2020

Semver matching #127

Semver matching #127

Conversation

GregBowyer commented Jan 30, 2020 • edited Loading

Semver Matching

acmcarther commented Jan 31, 2020

acmcarther commented Apr 1, 2020

GregBowyer commented Apr 2, 2020

UebelAndre commented Sep 9, 2020

GregBowyer commented Sep 9, 2020 via email

UebelAndre commented Sep 9, 2020

UebelAndre commented Sep 15, 2020

GregBowyer commented Oct 30, 2020

GregBowyer commented Oct 30, 2020

dfreese left a comment

Choose a reason for hiding this comment

dfreese commented Nov 6, 2020

dfreese commented Nov 6, 2020

GregBowyer commented Nov 7, 2020

UebelAndre commented Nov 7, 2020

GregBowyer commented Nov 7, 2020

UebelAndre commented Nov 7, 2020

GregBowyer commented Nov 7, 2020

dfreese commented Nov 7, 2020

UebelAndre commented Nov 7, 2020

dfreese commented Nov 7, 2020

GregBowyer commented Jan 30, 2020 •

edited

Loading