Wrong order of publishing

[chipshort]

We set up cargo-release for the https://github.com/CosmWasm/cosmwasm workspace, but it seems the order of publishing for crates is not detected correctly. It tries to publish the dependent before the dependency, resulting in a failure mid-publishing.

To reproduce:
From the release/2.2 branch in cosmwasm, run cargo release 2.2.0-rc.3 -x. It tries to publish cosmwasm-std before cosmwasm-schema even though the former has a dev-dependency on the latter. This causes cargo to fail publishing. Here are the relevant outputs for when I encountered this with rc.2:

Release
  cosmwasm-core 2.2.0-rc.2
  cosmwasm-crypto 2.2.0-rc.2
  cosmwasm-derive 2.2.0-rc.2
  cosmwasm-std 2.2.0-rc.2
  cosmwasm-vm-derive 2.2.0-rc.2
  cosmwasm-vm 2.2.0-rc.2
  cosmwasm-check 2.2.0-rc.2
  cosmwasm-schema-derive 2.2.0-rc.2
  cosmwasm-schema 2.2.0-rc.2

  Compiling cosmwasm-derive v2.2.0-rc.2 (/Users/christoph/Projects/cosmwasm/target/package/cosmwasm-derive-2.2.0-rc.2)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.78s
    Packaged 5 files, 14.5KiB (3.5KiB compressed)
   Uploading cosmwasm-derive v2.2.0-rc.2 (/Users/christoph/Projects/cosmwasm/packages/derive)
    Uploaded cosmwasm-derive v2.2.0-rc.2 to registry `crates-io`
note: waiting for `cosmwasm-derive v2.2.0-rc.2` to be available at registry `crates-io`.
You may press ctrl-c to skip waiting; the crate should be available shortly.
   Published cosmwasm-derive v2.2.0-rc.2 at registry `crates-io`
  Publishing cosmwasm-std
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   /Users/christoph/Projects/cosmwasm/packages/vm/Cargo.toml
workspace: /Users/christoph/Projects/cosmwasm/Cargo.toml
    Updating crates.io index
   Packaging cosmwasm-std v2.2.0-rc.2 (/Users/christoph/Projects/cosmwasm/packages/std)
   Verifying cosmwasm-std v2.2.0-rc.2 (/Users/christoph/Projects/cosmwasm/packages/std)
    Updating crates.io index
error: failed to verify package tarball

Caused by:
  failed to select a version for the requirement `cosmwasm-schema = "^2.2.0-rc.2"`
  candidate versions found which didn't match: 2.2.0-rc.1, 2.1.4, 2.1.3, ...
  location searched: crates.io index
  required by package `cosmwasm-std v2.2.0-rc.2 (/Users/christoph/Projects/cosmwasm/target/package/cosmwasm-std-2.2.0-rc.2)`
  if you are looking for the prerelease package it needs to be specified explicitly
      cosmwasm-schema = { version = "2.2.0-rc.1" }

Maybe the problem is that dev-dependencies are not factored into the ordering?

[epage]

We ignore dev-dependencies to break cycles

cargo-release/src/ops/cargo.rs

Lines 434 to 451 in 06a4e44

	// Ignore dev dependencies. This breaks dev dependency cyles and allows for
	// correct publishing order when a workspace package depends on the root package.
	// It would be more correct to ignore only dev dependencies without a version
	// field specified. However, cargo_metadata exposes only the resolved version of
	// a package, and not what semver range (if any) is requested in Cargo.toml.
	let non_dev_pkgs = n.deps.iter().filter_map(|dep| {
	let dev_only = dep
	.dep_kinds
	.iter()
	.all(|info| info.kind == cargo_metadata::DependencyKind::Development);
	if dev_only {
	None
	} else {
	Some(&dep.pkg)
	}

However, we should only do that if the package is missing a version

[psandana]

Hi @epage,

I experienced this issue today (I see it slightly related to #624). I understand we only can get the resolved version, not the specified version, but I think it is fine and expected by some users.

As it can also be of surprise for others, I propose to add a parameter to cargo-release that enables this behavior of considering resolved dev-dependency version to define the order. It could be something like: --use-dev-dependencies or just --dev-dependencies, or similar.

If you like this, I may get some time to propose the fix as a PR.

[epage]

A flag is the wrong tool for this. You don't know you need the flag until you've already hit the problem. You then have to remember it every time. This is more a property of your package and should be a config. Ideally, we would have a way to tell this on a users behalf, so they don't have to run into the problem first and have to investigate to find that what they need is a flag. That leads back to what I said before about finding a way to do this where we only skip them if they are local-only, like cargo publish.

[psandana]

Understood. One thing we can do is to filter out by the publish member in Package struct. From the docs:

publish: Option<Vec<String>>
    List of registries to which this package may be published (derived from the publish field).

    Publishing is unrestricted if None, and forbidden if the Vec is empty.

So, if publish is Some and Vec is empty, then we can safely assume it is a non-publishable dev-dependency and skip it. Does this logic make sense to you?

[epage]

publish = true is the default and so someone could have a dependency they don't publish that doesn't set publish = false. Making an assumption like that would just mean that we still strip dev-dependencies more than we should. So it is strictly an improvement over the current state though not fully fixed.

However, if work is being done to fix this, I think effort should be put towards a proper fix and not a hack. While a proper fix isn't as trivial, I'm hopeful its not burdensome to implement. If it is, then we can move forward with a hack.