-
Notifications
You must be signed in to change notification settings - Fork 105
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
Allow crate aliases #123
Allow crate aliases #123
Conversation
I guess I'll wait until #122 is in before reviewing this. Thanks for splitting these up, by the way! |
Probably want to wait on bazelbuild/rules_rust#285 too |
dc1b54b
to
0863e03
Compare
I reviewed 0863e03 , the change looks good to me. I'll wait for bazelbuild/rules_rust#285 though. Looks like that one is failing some tests. |
0863e03
to
26db04f
Compare
26db04f
to
af6a101
Compare
Back to WIP There are some changes I have queued up to allow the aliasing of things in the "root" Cargo.toml, as well as to make sure duplicates dont occur in aliases I will try to get those in later |
057a48d
to
4db33fd
Compare
49e222e
to
1b72ae6
Compare
1b72ae6
to
4ee77db
Compare
@GregBowyer Can I help out getting this merged? In need of this feature myself. |
I am also in need of this feature, can I help in any way ? |
@luna-duclos mostly we could do with unit / integration tests to make sure this doesnt have regressions. |
4ee77db
to
3cc6c0a
Compare
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
This turns out to be important for some fairly important crates. For example, consider the `futures-0.3.x` crates. This crate offers a feature (`compat`) that allows for the interaction with `futures01` codebases. Internally this is accomplished with the following dependency declaration ```toml [dependencies] futures_01 = { version = "0.1", package = "futures" } ``` This makes the crate futures-0.1.x available as a dependency to futures-0.3.x, but named in compilation as `futures_01`. The compilation environment uses the `--extern` flags for rustc to finish this remapping. This is exposed to rules_rust as an `alias` attribute, allowing rules_rust to honor these renames.
3cc6c0a
to
7496951
Compare
I think this was mostly handled by #162. I'm going to go ahead and close this, but feel free to reopen it if there's something that I missed. |
Allow for crates to be "renamed" in Cargo.toml, and expose these details to rules_rust (PR pending)
This is needed for futures to be built with
compat
as a feature, but could also be useful to alias out multiple versions of a package in a tree.