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

Implement the [patch] section of the manifest #4123

Merged
merged 1 commit into from
Jul 18, 2017

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jun 5, 2017

This is an implementation of RFC 1969 which adds a new section to top-level
manifests: [patch]. This section allows you to augment existing sources with
new versions of crates, possibly replacing the versions that already exist in
the source. More details about this feature can be found in the RFC itself.

@rust-highfive
Copy link

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

r? @matklad

@rust-highfive rust-highfive assigned matklad and unassigned brson Jun 5, 2017
@alexcrichton
Copy link
Member Author

Note that this shouldn't actually get merged until rust-lang/rfcs#1969 is merged, and I still need to update src/doc/*.md to document this new feature over [replace] as well. Other than that though the implementation should be ready for review!

@bors
Copy link
Contributor

bors commented Jun 5, 2017

☔ The latest upstream changes (presumably #4118) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Member

@matklad matklad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just given a really quick skim, and looks like all the tests test replace scenario, where we augment with the same version we already have. Would be nice to have some tests for second and third scenario from the RFC!

tests/augment.rs Outdated

#[test]
fn nonexistent() {
Package::new("baz", "0.1.0").publish();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, baz is not mentioned anywhere else in the tests?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this is used to route registry requests (e.g. updating the index) to the local version and not crates.io itself.

@alexcrichton
Copy link
Member Author

Sure yeah, pushed up some more tests. Some drafts of docs are up but they still need serious reworking (this is just whatever work I had done from awhile ago)

@@ -28,13 +29,15 @@ pub struct Manifest {
profiles: Profiles,
publish: bool,
replace: Vec<(PackageIdSpec, Dependency)>,
augment: HashMap<Url, Vec<Dependency>>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, specifying augment as a Dependency (that is, a constraint on possible versions) does not feel semantically right. What does it mean to augment a registry with foo 1.0.*?

Should we add a constraint that you must explicitelly add a =x.y.z constraint to the augment? This seems better from the theoretical pov, but I don't see any real benefits except perhaps for the better readability:

[augment.crates-io]
xml-rs = { git = "https://github.com/aturon/xml-rs", branch = "servo-fix" }

vs

[augment.crates-io]
xml-rs = { version = "0.9.2", git = "https://github.com/aturon/xml-rs", branch = "servo-fix" }

That is, I am a bit unsure about

Cargo will unconditionally resolve all entries in the [augment] section to precise dependencies, encoding them all in the lock file whether they're used or not.

section of the RFC. Should cargo really resolve entries in augment? What if it finds several versions of [augment] (it's not possible with git source, but may be possible with some theoretical other), which one should it choose?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see that we just bail if augment resolves to more than one summary!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the intention here was that the syntax of this section is the same as [dependencies], so we'd just store it as a vanilla Dependency. Then it only makes sense to augment with git sources or path sources, which only ever return one summary anyway, so it'd suffice for that.

/// Returns the root [augment] section of this workspace.
///
/// This may be from a virtual crate or an actual crate.
pub fn root_augment(&self) -> &HashMap<Url, Vec<Dependency>> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I correct that augment is only allowed in the root of the workspace? We should probably enforce this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, yeah. I'll look to adding enforcement.

format!("failed to resolve augments for `{}`", url)
})?;

*self.augments.entry(url.clone()).or_insert(Vec::new()) = deps;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks suspicious... It should be either augments.insert(url, deps) or augments.entry().or_insert().extend(deps).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like I originally had this as extend and later changed it to this. I'll update the code.

// name/version. Note that we don't use `dep.matches(..)` because
// the augmentations, by definition, come from a different source.
// This means that `dep.matches(..)` will always return false, when
// what we really care about is the name/version match.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add something like match_ignore_source to dependency, just to keep all related logic in one place? It's interesting that we need something similar for overrides (only_match_name thing), but the implementation there uses a different strategy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah old overrides are... odd...

In any case though the suggestion sounds good!

// check its results. We don't actually use any of the summaries it
// gives us though.
(Some(override_summary), Some(source)) => {
let mut n = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in this branch we should bail with an error if !augments.is_empty().

// Finally we check to see if any registered augments correspond to
// this dependency.
let v = augments.get(dep.source_id().url()).and_then(|vec| {
vec.iter().find(|s| {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add a sanity check here that we find at most one matching augment.

@@ -17,6 +17,12 @@ pub struct EncodableResolve {
/// `root` is optional to allow forward compatibility.
root: Option<EncodableDependency>,
metadata: Option<Metadata>,
augment: Option<Augment>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can use null object pattern and store augment: Augment, using an empty augment instead of None. Serialization can be tweaked separately:

#[serde(default)]
#[serde(skip_if = "Augment::is_empty")]
augment: Augment

@@ -325,10 +344,27 @@ impl<'a, 'cfg> ser::Serialize for WorkspaceResolve<'a, 'cfg> {
Some(root) if self.use_root_key => Some(encodable_resolve_node(&root, self.resolve)),
_ => None,
};

let augment = if self.resolve.unused_augments().len() == 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could use is_empty().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably irrelevant if we go with null object here :)

}
};
let augments = augments.iter().map(|dep| {
let unused = previous.unused_augments();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, what if previous contains some old augments, which are no longer present in the current Cargo.toml?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these'll just get dropped later, but I've added a test to assert this as well.


[RFC 1969]: https://github.com/rust-lang/rfcs/pull/1969
[replace]: specifying-dependencies.html#overriding-dependencies

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding docs, we have an overwhelming number of options to override a package from crates.io:

  • augment
  • replace
  • path overrides
  • path dependencies
  • vendoring

Perhaps we could create a new section "using non crates io depedendencies", which gives a flow chart style guide of choosing a right tool for the problem?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds plausible to me! I plan to focus on these docs once we land the RFC

self
}

fn _with_stderr(&mut self, expected: &ToString) {
self.expect_stderr = Some(expected.to_string());
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious, is this to improve compile times? Does it really help measurably?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It started off as that yeah, I was astounded at how long it took a "hello world" cargo test to compile so was randomly trying things to push down compile times, none of it ever ended up working though :(

@bors
Copy link
Contributor

bors commented Jul 11, 2017

☔ The latest upstream changes (presumably #4259) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton alexcrichton changed the title Implement the [augment] section of the manifest Implement the [patch] section of the manifest Jul 12, 2017
@alexcrichton
Copy link
Member Author

I've updated with documentation and a renaming to [patch], r? @matklad

@SimonSapin
Copy link
Contributor

Alright, building Cargo locally for testing brand-new features sounds reasonable (at least in terms of compile times compared to building rustc).

I’m not sure how to use it, though. Can I just copy target/release/cargo around, or does "installing" Cargo also involves copying some other files?

bors-servo pushed a commit to servo/servo that referenced this pull request Jul 18, 2017
Update to cargo 0.21.0-nightly (eb6cf012a 2017-07-02)

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17780)
<!-- Reviewable:end -->
@matklad
Copy link
Member

matklad commented Jul 18, 2017

Copying cargo binary should be fine. I usually do export CARGO_DEV=~/projects/cargo/target/dev/cargo and use $CARGO_DEV instead of cargo then.

@SimonSapin
Copy link
Contributor

@matklad When building Servo you don’t typically run Cargo directly, so it’s a little more involved. But I’ll figure something out.

@matklad
Copy link
Member

matklad commented Jul 18, 2017

Hm, I wonder if cargo install --git https://github.com/rust-lang/cargo --root ~/bin could help :)

I think you can even cargo install --git https://github.com/rust-lang/cargo --force =P

@SimonSapin
Copy link
Contributor

Interesting. But I think I’d rather have cargo be managed by rustup usually, and only when I want to test something specific compile from git.

bors-servo pushed a commit to servo/servo that referenced this pull request Jul 18, 2017
Update to cargo 0.21.0-nightly (eb6cf012a 2017-07-02)

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17780)
<!-- Reviewable:end -->
bors-servo pushed a commit to servo/servo that referenced this pull request Jul 18, 2017
Update to cargo 0.21.0-nightly (eb6cf012a 2017-07-02)

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17780)
<!-- Reviewable:end -->
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Jul 19, 2017
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c

--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5adb79e9d2a0446949f4ca8211496d96b41e648f
JerryShih pushed a commit to JerryShih/gecko-dev that referenced this pull request Jul 20, 2017
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c
leobalter pushed a commit to leobalter/gecko-dev that referenced this pull request Jul 20, 2017
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c
SimonSapin added a commit to SimonSapin/rust that referenced this pull request Jul 21, 2017
TimNN added a commit to TimNN/rust that referenced this pull request Jul 21, 2017
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b

rust-lang/cargo#4123 added the `[patch]` section of the manifest
bors added a commit to rust-lang/rust that referenced this pull request Jul 21, 2017
Update Cargo to ffab51954ec32d55631c37a8730bb24915fc090b

rust-lang/cargo#4123 added the `[patch]` section of the manifest
aethanyc pushed a commit to aethanyc/gecko-dev that referenced this pull request Jul 24, 2017
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c
jryans pushed a commit to jryans/gecko-dev that referenced this pull request Jul 25, 2017
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Nov 3, 2017
Changelog:
Version 1.21.0 (2017-10-12)
==========================

Language
--------
- [You can now use static references for literals.][43838]
  Example:
  ```rust
  fn main() {
      let x: &'static u32 = &0;
  }
  ```
- [Relaxed path syntax. Optional `::` before `<` is now allowed in all contexts.][43540]
  Example:
  ```rust
  my_macro!(Vec<i32>::new); // Always worked
  my_macro!(Vec::<i32>::new); // Now works
  ```

Compiler
--------
- [Upgraded jemalloc to 4.5.0][43911]
- [Enabled unwinding panics on Redox][43917]
- [Now runs LLVM in parallel during translation phase.][43506]
  This should reduce peak memory usage.

Libraries
---------
- [Generate builtin impls for `Clone` for all arrays and tuples that
  are `T: Clone`][43690]
- [`Stdin`, `Stdout`, and `Stderr` now implement `AsRawFd`.][43459]
- [`Rc` and `Arc` now implement `From<&[T]> where T: Clone`, `From<str>`,
  `From<String>`, `From<Box<T>> where T: ?Sized`, and `From<Vec<T>>`.][42565]

Stabilized APIs
---------------

[`std::mem::discriminant`]

Cargo
-----
- [You can now call `cargo install` with multiple package names][cargo/4216]
- [Cargo commands inside a virtual workspace will now implicitly
  pass `--all`][cargo/4335]
- [Added a `[patch]` section to `Cargo.toml` to handle
  prepublication dependencies][cargo/4123] [RFC 1969]
- [`include` & `exclude` fields in `Cargo.toml` now accept gitignore
  like patterns][cargo/4270]
- [Added the `--all-targets` option][cargo/4400]
- [Using required dependencies as a feature is now deprecated and emits
  a warning][cargo/4364]


Misc
----
- [Cargo docs are moving][43916]
  to [doc.rust-lang.org/cargo](https://doc.rust-lang.org/cargo)
- [The rustdoc book is now available][43863]
  at [doc.rust-lang.org/rustdoc](https://doc.rust-lang.org/rustdoc)
- [Added a preview of RLS has been made available through rustup][44204]
  Install with `rustup component add rls-preview`
- [`std::os` documentation for Unix, Linux, and Windows now appears on doc.rust-lang.org][43348]
  Previously only showed `std::os::unix`.

Compatibility Notes
-------------------
- [Changes in method matching against higher-ranked types][43880] This may cause
  breakage in subtyping corner cases. [A more in-depth explanation is available.][info/43880]
- [rustc's JSON error output's byte position start at top of file.][42973]
  Was previously relative to the rustc's internal `CodeMap` struct which
  required the unstable library `libsyntax` to correctly use.
- [`unused_results` lint no longer ignores booleans][43728]

[42565]: rust-lang/rust#42565
[42973]: rust-lang/rust#42973
[43348]: rust-lang/rust#43348
[43459]: rust-lang/rust#43459
[43506]: rust-lang/rust#43506
[43540]: rust-lang/rust#43540
[43690]: rust-lang/rust#43690
[43728]: rust-lang/rust#43728
[43838]: rust-lang/rust#43838
[43863]: rust-lang/rust#43863
[43880]: rust-lang/rust#43880
[43911]: rust-lang/rust#43911
[43916]: rust-lang/rust#43916
[43917]: rust-lang/rust#43917
[44204]: rust-lang/rust#44204
[cargo/4123]: rust-lang/cargo#4123
[cargo/4216]: rust-lang/cargo#4216
[cargo/4270]: rust-lang/cargo#4270
[cargo/4335]: rust-lang/cargo#4335
[cargo/4364]: rust-lang/cargo#4364
[cargo/4400]: rust-lang/cargo#4400
[RFC 1969]: rust-lang/rfcs#1969
[info/43880]: rust-lang/rust#44224 (comment)
[`std::mem::discriminant`]: https://doc.rust-lang.org/std/mem/fn.discriminant.html
@Eh2406 Eh2406 mentioned this pull request Jul 27, 2019
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 1, 2019
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c

UltraBlame original commit: 380ad1bfb187a075e540ffaf07e2c104d6c00a13
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 1, 2019
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c

UltraBlame original commit: 380ad1bfb187a075e540ffaf07e2c104d6c00a13
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 1, 2019
…07-02) (from servo:cargoup); r=nox,SimonSapin

Cargo binaries are now produced on Rust’s CI, not Cargo’s. Remove cargo-commit-hash and find Cargo based on rust-commit-hash.

Unfortunately, Cargo binaries are not available for every Cargo PR anymore: rust-lang/cargo#4123 (comment)

Source-Repo: https://github.com/servo/servo
Source-Revision: d403f404382c66485d9744787ce021556be59d6c

UltraBlame original commit: 380ad1bfb187a075e540ffaf07e2c104d6c00a13
@ehuss ehuss added this to the 1.21.0 milestone Feb 6, 2022
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.

7 participants