Implement workspaces in Cargo #2759

Merged
merged 1 commit into from Jul 5, 2016

Conversation

Projects
None yet
8 participants
@alexcrichton
Member

alexcrichton commented May 31, 2016

This commit is an implementation of RFC 1525 which specifies the addition of
workspaces to Cargo.

A workspace is a group of crates which are all compiled into the same output
directory and share the same Cargo.lock file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root Cargo.toml:

[workspace]

Otherwise more advanced configuration may be necessary through the
package.workspace or workspace.members keys. More information can be found
as part of RFC 1525.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive May 31, 2016

r? @wycats

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

r? @wycats

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

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 31, 2016

Member

I wanted to put this up for review, but I don't think that this is ready to merge yet. I believe I've covered the bases of an implementation, tests, and documentation. So far [workspace] and virtual manifests are both implemented.

In implementing this I can only think of one possible catch in the RFC, which is that workspace.members is only filled in automatically if it's not present. The filling in happens transitively through path dependencies. This however does not play nicely with virtual manifests because there are no implicit path dependencies. This means that all virtual manifests would have to exhaustively list out members of the workspace, which can sometimes be tedious. I might recommend tweaking the RFC to say that "path dependencies of workspace members are always transitively included in a workspace". I'm not sure if this is too restrictive, however, as there's no way to turn off this behavior. For now this implements what was in the RFC.

The major piece that this has not implemented yet is the modification to cargo new. The intention was to have cargo new basically automatically manage your workspace so you never have to do so yourself. That is, heuristics like this would be implemented:

  • Whenever a new root crate is created, a [workspace] key is filled in.
  • Whenever a child crate is created in a subdirectory, it's connected to that workspace.

Unfortunately connecting a crate to a workspace is not always a simple and local operation. We can always provide a pointer back to the workspace (e.g. package.workspace), but the original root must contain the new crate in its workspace. The only way to do that is to list it in workspace.members or list it as a path dependency. Because this is a new crate it probably isn't listed as a path dependency, so it'll have to be added to workspace.members. Eventually, however, it'll probably be added as a path dependency and this won't be necessary.

I've left this unimplemented for now as I'm unsure what the best way to move forward this would be. On one hand if we omit [workspace] as part of cargo new we don't have any problems (e.g. what we do today), but you don't get the benefit of workspaces by default (which probably everyone wants). If we do emit [workspace] by default then we'll at least need to add the ability to read/write TOML which round trips comments and formatting. This would then likely also entail auto-adding an entry to [dependencies] or auto-adding an entry to workspace.members, both of which are implementable but somewhat complicated.

Curious on others' thoughts though!

cc @wycats
cc @brson
cc @rust-lang/tools

Member

alexcrichton commented May 31, 2016

I wanted to put this up for review, but I don't think that this is ready to merge yet. I believe I've covered the bases of an implementation, tests, and documentation. So far [workspace] and virtual manifests are both implemented.

In implementing this I can only think of one possible catch in the RFC, which is that workspace.members is only filled in automatically if it's not present. The filling in happens transitively through path dependencies. This however does not play nicely with virtual manifests because there are no implicit path dependencies. This means that all virtual manifests would have to exhaustively list out members of the workspace, which can sometimes be tedious. I might recommend tweaking the RFC to say that "path dependencies of workspace members are always transitively included in a workspace". I'm not sure if this is too restrictive, however, as there's no way to turn off this behavior. For now this implements what was in the RFC.

The major piece that this has not implemented yet is the modification to cargo new. The intention was to have cargo new basically automatically manage your workspace so you never have to do so yourself. That is, heuristics like this would be implemented:

  • Whenever a new root crate is created, a [workspace] key is filled in.
  • Whenever a child crate is created in a subdirectory, it's connected to that workspace.

Unfortunately connecting a crate to a workspace is not always a simple and local operation. We can always provide a pointer back to the workspace (e.g. package.workspace), but the original root must contain the new crate in its workspace. The only way to do that is to list it in workspace.members or list it as a path dependency. Because this is a new crate it probably isn't listed as a path dependency, so it'll have to be added to workspace.members. Eventually, however, it'll probably be added as a path dependency and this won't be necessary.

I've left this unimplemented for now as I'm unsure what the best way to move forward this would be. On one hand if we omit [workspace] as part of cargo new we don't have any problems (e.g. what we do today), but you don't get the benefit of workspaces by default (which probably everyone wants). If we do emit [workspace] by default then we'll at least need to add the ability to read/write TOML which round trips comments and formatting. This would then likely also entail auto-adding an entry to [dependencies] or auto-adding an entry to workspace.members, both of which are implementable but somewhat complicated.

Curious on others' thoughts though!

cc @wycats
cc @brson
cc @rust-lang/tools

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jun 5, 2016

Contributor

I might recommend tweaking the RFC to say that "path dependencies of workspace members are always transitively included in a workspace".

Those transitive deps still need to specify the virtual manifest as workspace root, or be in a subdirectory, for symmetry, right?

Contributor

Ericson2314 commented Jun 5, 2016

I might recommend tweaking the RFC to say that "path dependencies of workspace members are always transitively included in a workspace".

Those transitive deps still need to specify the virtual manifest as workspace root, or be in a subdirectory, for symmetry, right?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 5, 2016

Member

No, they're typically lower in the filesystem hierarchy.

Member

alexcrichton commented Jun 5, 2016

No, they're typically lower in the filesystem hierarchy.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jun 5, 2016

Contributor

Hmm? You mean the subtree with virtual manifest at its root contains the specified members' path dependencies---what I meant by "or be in a subdirectory", or something else?

Contributor

Ericson2314 commented Jun 5, 2016

Hmm? You mean the subtree with virtual manifest at its root contains the specified members' path dependencies---what I meant by "or be in a subdirectory", or something else?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 6, 2016

Member

Ah yes I misread, the original statement you made is correct (it just follows from what was written in the RFC)

Member

alexcrichton commented Jun 6, 2016

Ah yes I misread, the original statement you made is correct (it just follows from what was written in the RFC)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 20, 2016

Member

ping r? @brson, thoughts?

Member

alexcrichton commented Jun 20, 2016

ping r? @brson, thoughts?

@rust-highfive rust-highfive assigned brson and unassigned wycats Jun 20, 2016

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 21, 2016

Contributor

I know I need to read this one closely and I just haven't yet.

Contributor

brson commented Jun 21, 2016

I know I need to read this one closely and I just haven't yet.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 21, 2016

Member

Ah yeah sure, we should talk in person tomorrow as well

Member

alexcrichton commented Jun 21, 2016

Ah yeah sure, we should talk in person tomorrow as well

+ name = "bar"
+ version = "0.1.0"
+ authors = []
+ workspace = ".."

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

This 'workspace' key is under project, but the RFC says it goes under 'package'. Why the discrepancy?

@brson

brson Jun 21, 2016

Contributor

This 'workspace' key is under project, but the RFC says it goes under 'package'. Why the discrepancy?

This comment has been minimized.

@alexcrichton

alexcrichton Jun 21, 2016

Member

Oh the [package] and [project] keys are actually synonymous right now. There were initial ideas of how to treat them differently but that never came to fruition, so it's it's just a semi-unfortunate legacy "feature"

@alexcrichton

alexcrichton Jun 21, 2016

Member

Oh the [package] and [project] keys are actually synonymous right now. There were initial ideas of how to treat them differently but that never came to fruition, so it's it's just a semi-unfortunate legacy "feature"

+ .with_stderr("\
+error: current package believes it's in a workspace when it's not:
+current: [..]Cargo.toml
+workspace: [..]Cargo.toml

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

Is it appropriate for this error to provide a hint to add it to members?

@brson

brson Jun 21, 2016

Contributor

Is it appropriate for this error to provide a hint to add it to members?

tests/workspaces.rs
+ .file("bar/src/main.rs", "fn main() {}");
+ p.build();
+
+ assert_that(p.cargo("build"), execs().with_status(101));

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

Is this a panic? Why doesn't it generate a proper error?

@brson

brson Jun 21, 2016

Contributor

Is this a panic? Why doesn't it generate a proper error?

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

Nvm, I was assuming error 101 meant panic, but that's not the case.

@brson

brson Jun 21, 2016

Contributor

Nvm, I was assuming error 101 meant panic, but that's not the case.

src/cargo/core/workspace.rs
+ packages: Packages<'cfg>,
+ root_manifest: Option<PathBuf>,
+ members: Vec<PathBuf>,
+}

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

Can you add a comment explaining the difference between current_manifest, root_manifest, and members?

@brson

brson Jun 21, 2016

Contributor

Can you add a comment explaining the difference between current_manifest, root_manifest, and members?

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

And why root_manifest would be none.

@brson

brson Jun 21, 2016

Contributor

And why root_manifest would be none.

src/cargo/core/workspace.rs
+ }
+
+ None => self.find_path_deps(&root_manifest),
+ }

This comment has been minimized.

@brson

brson Jun 21, 2016

Contributor

In the case here that members is Some(list), where does it recurse and find the transitive members of the workspace? It looks to me like it just loops over the explicit members of the workspace root, adds them, and does no more.

Again in the case where members is Some(list) where are the path deps loaded? It looks like when any members are explicitly listed under [workspace] then it doesn't bother finding members from path deps.

@brson

brson Jun 21, 2016

Contributor

In the case here that members is Some(list), where does it recurse and find the transitive members of the workspace? It looks to me like it just loops over the explicit members of the workspace root, adds them, and does no more.

Again in the case where members is Some(list) where are the path deps loaded? It looks like when any members are explicitly listed under [workspace] then it doesn't bother finding members from path deps.

This comment has been minimized.

@alexcrichton

alexcrichton Jun 21, 2016

Member

Ah this is actually an implementation strictly following the RFC. I have come to think that it may be better to just always transitively follow members of the workspace via path dependencies to find more members, however, as that's somewhat more intuitive and more ergonomic I think.

@alexcrichton

alexcrichton Jun 21, 2016

Member

Ah this is actually an implementation strictly following the RFC. I have come to think that it may be better to just always transitively follow members of the workspace via path dependencies to find more members, however, as that's somewhat more intuitive and more ergonomic I think.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 21, 2016

Contributor

Great patch. This integrates really cleanly for such a big feature.

Contributor

brson commented Jun 21, 2016

Great patch. This integrates really cleanly for such a big feature.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jun 23, 2016

Member

I'll work on some better error messages, but @wycats do you have thoughts about the implicitly traveling all path dependencies in the members array unconditionally?

Member

alexcrichton commented Jun 23, 2016

I'll work on some better error messages, but @wycats do you have thoughts about the implicitly traveling all path dependencies in the members array unconditionally?

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 1, 2016

Member

Ok, after some more discussion with @wycats and @brson offline, I've updated the PR with two new pieces:

  • Path dependencies are always transitively traversed, including packages which are explicitly mentioned in workspace.members, as well as when some members are explicitly listed.
  • cargo new and cargo init will now issue a warning if they detect that a crate was just created with invalid workspace configuration. This is the best we can do for now without automatically updating configuration for you, and should hopefully tie us over to when that happens.

Due to the size of this feature and the concerns of the @rust-lang/tools team, r? @brson but this should probably merge after we branch beta next week.

Member

alexcrichton commented Jul 1, 2016

Ok, after some more discussion with @wycats and @brson offline, I've updated the PR with two new pieces:

  • Path dependencies are always transitively traversed, including packages which are explicitly mentioned in workspace.members, as well as when some members are explicitly listed.
  • cargo new and cargo init will now issue a warning if they detect that a crate was just created with invalid workspace configuration. This is the best we can do for now without automatically updating configuration for you, and should hopefully tie us over to when that happens.

Due to the size of this feature and the concerns of the @rust-lang/tools team, r? @brson but this should probably merge after we branch beta next week.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 1, 2016

Member

@larsbergstrom as a heads up, this is what it looks like for me to add workspaces to Servo (probably incomplete) alexcrichton/servo@1094428.

I found it cool that the top-level Cargo.toml has a pretty small workspace.members list, and I imagine it'll also be nice get rid of all those pesky duplicate Cargo.lock files!

It looked like there were spurious rebuilds between switching build and build-geckolib (build and build-cef were fine) but it looked to be related to legitimate issues rather than versions being swapped out.

In any case, just wanted to ensure that it worked at scale, and it looks like it's working like a charm!

Member

alexcrichton commented Jul 1, 2016

@larsbergstrom as a heads up, this is what it looks like for me to add workspaces to Servo (probably incomplete) alexcrichton/servo@1094428.

I found it cool that the top-level Cargo.toml has a pretty small workspace.members list, and I imagine it'll also be nice get rid of all those pesky duplicate Cargo.lock files!

It looked like there were spurious rebuilds between switching build and build-geckolib (build and build-cef were fine) but it looked to be related to legitimate issues rather than versions being swapped out.

In any case, just wanted to ensure that it worked at scale, and it looks like it's working like a charm!

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 1, 2016

Contributor

r=me

Contributor

brson commented Jul 1, 2016

r=me

@larsbergstrom

This comment has been minimized.

Show comment
Hide comment
@larsbergstrom

larsbergstrom Jul 2, 2016

@alexcrichton Thanks for trying that out - it looks REALLY fantastic!

One area of questioning: @SimonSapin is doing some work to help us do a dual-build using Rust Stable for just the geckolib target. Do you have any ideas for how that should integrate into this? And, can we still share the Cargo.lock file across nightly/stable builds?

IIRC, we will need separate target directories for the two builds, but since it's mainly a CI thing, I'm not super concerned about it.

@alexcrichton Thanks for trying that out - it looks REALLY fantastic!

One area of questioning: @SimonSapin is doing some work to help us do a dual-build using Rust Stable for just the geckolib target. Do you have any ideas for how that should integrate into this? And, can we still share the Cargo.lock file across nightly/stable builds?

IIRC, we will need separate target directories for the two builds, but since it's mainly a CI thing, I'm not super concerned about it.

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jul 2, 2016

Contributor

@larsbergstrom perhaps I misunderstand, but Cargo has long been able to compile multiple targets with a single target/ directory. When the --target <triple> flag is passed, the build artifacts go inside target/<triple>.

Contributor

Ericson2314 commented Jul 2, 2016

@larsbergstrom perhaps I misunderstand, but Cargo has long been able to compile multiple targets with a single target/ directory. When the --target <triple> flag is passed, the build artifacts go inside target/<triple>.

@larsbergstrom

This comment has been minimized.

Show comment
Hide comment
@larsbergstrom

larsbergstrom Jul 2, 2016

@Ericson2314 Aha, yes! The difference here is that it's the same target triple, but with different versions of the Rust compiler itself (the stable versus nightly releases).

@Ericson2314 Aha, yes! The difference here is that it's the same target triple, but with different versions of the Rust compiler itself (the stable versus nightly releases).

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 2, 2016

Member

@larsbergstrom for the "best experience" you'll probably want to use the same Cargo for now but perhaps with different Rust compilers. For example the stable Cargo right now doesn't understand workspaces so it won't be compatible with this. In general, though, as long as something too fundamental hasn't changed an older Cargo should be able to build against a newer Cargo.lock so long as the dependencies haven't changed.

You're also likely to definitely have lots of recompilations if you switch targets between geckolib and Servo because of the changing compilers, but everything should work on the Cargo side at least if you use the same Cargo compiler.

Member

alexcrichton commented Jul 2, 2016

@larsbergstrom for the "best experience" you'll probably want to use the same Cargo for now but perhaps with different Rust compilers. For example the stable Cargo right now doesn't understand workspaces so it won't be compatible with this. In general, though, as long as something too fundamental hasn't changed an older Cargo should be able to build against a newer Cargo.lock so long as the dependencies haven't changed.

You're also likely to definitely have lots of recompilations if you switch targets between geckolib and Servo because of the changing compilers, but everything should work on the Cargo side at least if you use the same Cargo compiler.

@larsbergstrom

This comment has been minimized.

Show comment
Hide comment
@larsbergstrom

larsbergstrom Jul 3, 2016

@alexcrichton Thanks, that all sounds totally perfect!

We can try using a shared target path for the rebuild of geckolib with stable, but I suspect that we'll want a separate, clean target path for that one. Native dependency builds are often a bit flaky w.r.t. non-trivial incremental rebuilds. We'll see how it goes!

@alexcrichton Thanks, that all sounds totally perfect!

We can try using a shared target path for the rebuild of geckolib with stable, but I suspect that we'll want a separate, clean target path for that one. Native dependency builds are often a bit flaky w.r.t. non-trivial incremental rebuilds. We'll see how it goes!

@Ericson2314

This comment has been minimized.

Show comment
Hide comment
@Ericson2314

Ericson2314 Jul 3, 2016

Contributor

@larsbergstrom @alexcrichton simple solution would be target/<compiler-version>/<target>/ right?

Contributor

Ericson2314 commented Jul 3, 2016

@larsbergstrom @alexcrichton simple solution would be target/<compiler-version>/<target>/ right?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jul 3, 2016

Contributor

@larsbergstrom A single workspace with a single Cargo.lock and multiple target directories (CARGO_TARGET_DIR environment variable, one per compiler version) should work fine, right?

@alexcrichton Yes, we already bootstrap and update Cargo separately from rustc, so I expect we’ll have one Cargo version for both rustc versions.

Contributor

SimonSapin commented Jul 3, 2016

@larsbergstrom A single workspace with a single Cargo.lock and multiple target directories (CARGO_TARGET_DIR environment variable, one per compiler version) should work fine, right?

@alexcrichton Yes, we already bootstrap and update Cargo separately from rustc, so I expect we’ll have one Cargo version for both rustc versions.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 5, 2016

Member

Beta cargo has now been selected, I'm going to r+ this

@bors: r=brson

Member

alexcrichton commented Jul 5, 2016

Beta cargo has now been selected, I'm going to r+ this

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

📌 Commit 72749ab has been approved by brson

Contributor

bors commented Jul 5, 2016

📌 Commit 72749ab has been approved by brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

⌛️ Testing commit 72749ab with merge 9b9a4a3...

Contributor

bors commented Jul 5, 2016

⌛️ Testing commit 72749ab with merge 9b9a4a3...

bors added a commit that referenced this pull request Jul 5, 2016

Auto merge of #2759 - alexcrichton:workspaces, r=brson
Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

💔 Test failed - cargo-win-gnu-32

Contributor

bors commented Jul 5, 2016

💔 Test failed - cargo-win-gnu-32

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 5, 2016

Member

@bors: r=brson

Member

alexcrichton commented Jul 5, 2016

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

📌 Commit 8b3933d has been approved by brson

Contributor

bors commented Jul 5, 2016

📌 Commit 8b3933d has been approved by brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

⌛️ Testing commit 8b3933d with merge 2af552d...

Contributor

bors commented Jul 5, 2016

⌛️ Testing commit 8b3933d with merge 2af552d...

bors added a commit that referenced this pull request Jul 5, 2016

Auto merge of #2759 - alexcrichton:workspaces, r=brson
Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

💔 Test failed - cargo-cross-linux

Contributor

bors commented Jul 5, 2016

💔 Test failed - cargo-cross-linux

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 5, 2016

Member

@bors: r=brson

Member

alexcrichton commented Jul 5, 2016

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

📌 Commit 0c2ee50 has been approved by brson

Contributor

bors commented Jul 5, 2016

📌 Commit 0c2ee50 has been approved by brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

⌛️ Testing commit 0c2ee50 with merge 23f2962...

Contributor

bors commented Jul 5, 2016

⌛️ Testing commit 0c2ee50 with merge 23f2962...

bors added a commit that referenced this pull request Jul 5, 2016

Auto merge of #2759 - alexcrichton:workspaces, r=brson
Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

💔 Test failed - cargo-win-msvc-64

Contributor

bors commented Jul 5, 2016

💔 Test failed - cargo-win-msvc-64

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 5, 2016

Member

@bors: r=brson

Member

alexcrichton commented Jul 5, 2016

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

📌 Commit 9a6aebe has been approved by brson

Contributor

bors commented Jul 5, 2016

📌 Commit 9a6aebe has been approved by brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

⌛️ Testing commit 9a6aebe with merge 4daf6b5...

Contributor

bors commented Jul 5, 2016

⌛️ Testing commit 9a6aebe with merge 4daf6b5...

bors added a commit that referenced this pull request Jul 5, 2016

Auto merge of #2759 - alexcrichton:workspaces, r=brson
Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

💔 Test failed - cargo-linux-64

Contributor

bors commented Jul 5, 2016

💔 Test failed - cargo-linux-64

Implement workspaces in Cargo
This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 5, 2016

Member

@bors: r=brson

Member

alexcrichton commented Jul 5, 2016

@bors: r=brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

📌 Commit 58ddb28 has been approved by brson

Contributor

bors commented Jul 5, 2016

📌 Commit 58ddb28 has been approved by brson

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Jul 5, 2016

Contributor

⌛️ Testing commit 58ddb28 with merge b036f19...

Contributor

bors commented Jul 5, 2016

⌛️ Testing commit 58ddb28 with merge b036f19...

bors added a commit that referenced this pull request Jul 5, 2016

Auto merge of #2759 - alexcrichton:workspaces, r=brson
Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].
@bors

This comment has been minimized.

Show comment
Hide comment
Contributor

bors commented Jul 5, 2016

@bors bors merged commit 58ddb28 into rust-lang:master Jul 5, 2016

1 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
homu Test successful
Details

@alexcrichton alexcrichton deleted the alexcrichton:workspaces branch Jul 5, 2016

@alexcrichton alexcrichton referenced this pull request in rust-lang/rust Jul 6, 2016

Closed

rustbuild: Ensure that it's ready for distros #34687

1 of 2 tasks complete

@rphmeier rphmeier referenced this pull request in paritytech/parity-ethereum Jul 11, 2016

Closed

Use cargo workspaces when they stabilize #1582

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment