Kristoffer Carlsson

Read this now https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html, which seems to be a quite similar thing.

Some updates here after talking with @fredrikekre - There should be one Manifest, and that is next to the main project. That collects the full dependency graph. - The main...

Everything gets resolved in one step. You collect all deps, and all compat and then run the resolver. The result gets put in the main `Manifest.toml`. I don't get what...

It is a problem and will not resolve. All your subprojects need to be compatible. One of the major points is to be able to use one manifest for all...

> Could the sub-project Project.toml have an entry parentproject in it instead that points to the parent Project.toml, and then the one level deeper constraint could be dropped? In that...

> that I think it's beneficial to have, even for a library package, a Manifest.toml for the tests, including for test-specific dependencies. There could also be perf-benchmarking specific dependencies. You...

> I would like to specify (at least partially) the exact dependencies. You mean using the `[compat]` section? I'm not sure what you mean otherwise, the exact dependencies are those...

The manifest records the exact versions of everything in your project. The `Project.toml` can set version bounds on packages so that the resolver will always give versions within those bounds....

> It enforces a constraint that your benchmark subproject and your test subproject use the same version of any shared dependencies. Is there a benefit to that? This is related...

> If the sub-project manifest has a full set of direct and transitive dependencies, there is nothing to resolve. Isn't it simpler? I mean, the point of a sub-project is...