How can Cargo help

[Eh2406]

At the Cargo Team Meeting today we discussed the importance of crates like this one. We decided to reach out to discuss how best to work together. How can we insure that the projects are kept smoothly uptodate with each other? What else can the Cargo team do to make sure we don't accidentally break this project? How can the Cargo team make sure that changes get included here promptly? Can we / Should we share code?

cc @ehuss who already got started in #61
and @dwijnand had some suggestions in rust-lang/cargo#6534

Also this idea should be expanded to Cargos other outputs. Should that be done here, or in some other existing crate, or in some new Cargo Team maintained crate?

cc @epage as this relates to the discussion in #45

[epage]

Also this idea should be expanded to Cargos other outputs. Should that be done here, or in some other existing crate, or in some new Cargo Team maintained crate?

#53 and https://github.com/crate-ci/escargot/ have cargo build output.

On a related note, --message-format for cargo test doesn't have any value from what I can see because it will print the messages for the build but then switch to dumping the test programs output without any delimiter. I'd love to have a way to get actual test failure information programmatically.

[ehuss]

test failure information programmatically

Are you talking about the libtest json output or something different? i.e., today you can get test information with cargo +nightly test --message-format=json -- --format=json -Zunstable-options. It's not stable, and it's not clear what it's future will look like with custom test frameworks. I also wish it included more information like filename/line numbers.

[epage]

Was not aware of that unstable feature, thanks! I can understand the challenge of stablizing it.

[oli-obk]

I think sharing the datastructures in a common crate would solve most compatibility issues. If cargo does a backwards compatible change to the datastructures, everyone gets the update for free (via minor bumps), if it's a breaking change, we also bump cargo_metadata.

For the diagnostics json datastructures I also want to push for rustc to share the crates.io datastructures.

[dwijnand]

A few questions:

1. Should the crates share the same versioning as cargo or not?

2. ... and if they're the same version keeping them in the cargo repo makes more sense (to me), but they don't, should they be in the cargo repo or not?

3. ... and if they're in the same repo, do they sync releases or can they be released independently?

So many questions 😄 I ask because I thought I read somewhere it's a pain to release in repo, maybe because of rust-lang/cargo#1169 ?

[oli-obk]

Should the crates share the same versioning as cargo or not?

No, I think they should be versioned by their changes according to semver

2 & 3

Well. I think they should have their own repos, we can publish changes to the datastructure crates before publishing the corresponding cargo change. Of course you can't merge a cargo PR without the datastructure PR having been merged.

Experimental things can be added to a nightly feature on the datastructure crate without many formalities. The nightly feature should use some rustc feature just to make sure it actually only works on nightly.

[dwijnand]

Agreed! They should have their own stable versions, and to make cargo and cargo_metadata (and other projects) equal citizens the crates should be in another repo. Cargo's ability to override dependencies with git repos makes this more workable (IMHO).

[Eh2406]

At the Cargo Team Meeting today we discussed this. The Team is open to pulling the tipes out into a public Crate with a sember based version number! The consensus was to start with a crate that lives in the Cargo repo, instead of having its own repo, at least for now.