crate-ci/cargo-release

Handle package cycles

Closed this issue · 7 comments

epage commented

clap has one (clap_derive runs tests against clap) and gitoxide has one. See @Byron's comment in #224,

The question is how to handle it.

  • We might be able to break at dev-dependencies without issue
  • It sounds like gitoxide just skips verification with cycles, This makes me feel a bit uneasy
Byron commented

It sounds like gitoxide just skips verification with cycles, This makes me feel a bit uneasy

Me too 😅. Maybe with the power of the crowd we can find a better way.

epage commented

For dev-dependencies @pksunkara is suggesting only declaring a path dependency, without a version, and it just works.

Things to verify as part of this

  • We gracefully handle no version
  • We create the correct ordering
epage commented

@Byron we've loosened things up so dev-dependencies don't have to declare version requirements. We rely on cargo to do the dependency ordering for us, so I hope they do it right. So with those combined, I'm hoping this is resolved but leaving it open for now to give us time to explore and remove the doubts.

pksunkara commented

We rely on cargo to do the dependency ordering for us, so I hope they do it right

What do you mean by that?

Byron commented

@epage I love the work you have done as well as the new information posted here. For instance, not having to specify the version of dev dependencies to remove the cycle really is awesome news.

@pksunkara I believe it's about using cargo's build resolution order which is specified in the "resolve.nodes" section of the cargo metadata.

epage commented

@pksunkara I believe it's about using cargo's build resolution order which is specified in the "resolve.nodes" section of the cargo metadata.

Yes, that is exactly what we are doing

epage commented

Assuming this is resolved