Allow for aliases at the top level #187

GregBowyer · 2020-07-20T23:44:38Z

So in closing out #123 for #162 an important use case was missed, that of allowing top level aliases in the cargo that raze itself is going to load.

This is pretty important for large monorepos where doing a full migration of types upfront is pretty challenging.

Previously aliases could only exist inside targets that cargo-raze
depends on and not in the raze "root" crate itself.

This means that a construction such as the following

bytes = "2.0"
bytes_old = { version = "1.0", package = "bytes" }

Could not allow for the production of top level bazel aliases such as:

"//cargo:bytes",
"//cargo:bytes_old",

This naturally turns up in larger codebases where migrartions are in
progress from one crate to another.

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

Previously aliases could only exist inside targets that cargo-raze depends on and not in the raze "root" crate itself. This means that a construction such as the following ```toml bytes = "2.0" bytes_old = { version = "1.0", package = "bytes" } ``` Could not allow for the production of top level bazel aliases such as: ```python "//cargo:bytes", "//cargo:bytes_old", ``` This naturally turns up in larger codebases where migrartions are in progress from one crate to another.

GregBowyer · 2020-07-21T20:52:45Z

This depends on #127 to have the version expressed in the model as a version and not a string, its possible to detangle this but I think we should land #127 then this

…kages There are a range of subtle and irritating bugs that stem from attempting to work with renames from the package set provided by cargo metadata. Fortunatly, recent versions of cargo metadata provide a limited version of the resolve nodes, both as the original node ids and as a newer set providing both rename and targetting information. As such we can (hopefully) simplify crate -> dep node resolution, remove a bunch of sublte aliasing bugs. Fixes google#241, fixes google#269, fixes google#270, resolves google#144, resolves google#187

GregBowyer · 2020-11-07T00:03:17Z

This is dead in favor of #282

…kages There are a range of subtle and irritating bugs that stem from attempting to work with renames from the package set provided by cargo metadata. Fortunatly, recent versions of cargo metadata provide a limited version of the resolve nodes, both as the original node ids and as a newer set providing both rename and targetting information. As such we can (hopefully) simplify crate -> dep node resolution, remove a bunch of sublte aliasing bugs. Fixes google#241, fixes google#269, fixes google#270, resolves google#144, resolves google#187

There are a range of subtle and irritating bugs that stem from attempting to work with renames from the package set provided by cargo metadata. Fortunately, recent versions of cargo metadata provide a limited version of the resolve nodes, both as the original node ids and as a newer set providing both rename and targeting information. As such we can (hopefully) simplify crate -> dep node resolution, remove a bunch of subtle aliasing bugs. Fixes google#241, fixes google#269, fixes google#270, resolves google#144, resolves google#187

There are a range of subtle and irritating bugs that stem from attempting to work with renames from the package set provided by cargo metadata. Fortunately, recent versions of cargo metadata provide a limited version of the resolve nodes, both as the original node ids and as a newer set providing both rename and targeting information. As such we can (hopefully) simplify crate -> dep node resolution, remove a bunch of subtle aliasing bugs. Fixes #241, fixes #269, fixes #270, resolves #144, resolves #187

GregBowyer mentioned this pull request Jul 21, 2020

Can I have two different versions of the same Rust library in one Bazel project? #144

Closed

GregBowyer force-pushed the aliases-at-root branch from e5f4afe to 1c70ba7 Compare July 21, 2020 20:51

This was referenced Nov 4, 2020

Incorrect rand alias generation for libsecp256k1 crate #270

Closed

Erroneous aliases for async-global-executor-1.4.2 #269

Closed

GregBowyer mentioned this pull request Nov 6, 2020

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

Closed

GregBowyer closed this Nov 7, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow for aliases at the top level #187

Allow for aliases at the top level #187

GregBowyer commented Jul 20, 2020

GregBowyer commented Jul 21, 2020

GregBowyer commented Nov 7, 2020

Allow for aliases at the top level #187

Allow for aliases at the top level #187

Conversation

GregBowyer commented Jul 20, 2020

GregBowyer commented Jul 21, 2020

GregBowyer commented Nov 7, 2020