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

Allow crate aliases #123

Closed
wants to merge 4 commits into from
Closed

Conversation

GregBowyer
Copy link
Contributor

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.

@acmcarther
Copy link
Member

I guess I'll wait until #122 is in before reviewing this. Thanks for splitting these up, by the way!

@GregBowyer
Copy link
Contributor Author

Probably want to wait on bazelbuild/rules_rust#285 too

@acmcarther
Copy link
Member

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.

impl/src/planning.rs Outdated Show resolved Hide resolved
@GregBowyer
Copy link
Contributor Author

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

@KaiserKarel
Copy link

@GregBowyer Can I help out getting this merged? In need of this feature myself.

@luna-duclos
Copy link

I am also in need of this feature, can I help in any way ?

@GregBowyer
Copy link
Contributor Author

@luna-duclos mostly we could do with unit / integration tests to make sure this doesnt have regressions.

@GregBowyer GregBowyer force-pushed the allow-crate-aliases branch from 4ee77db to 3cc6c0a Compare April 29, 2020 18:28
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.
@dfreese
Copy link
Collaborator

dfreese commented Jun 10, 2020

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.

@dfreese dfreese closed this Jun 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants