Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Release fails due to dependency conflict #393

Closed
Nukesor opened this issue Nov 21, 2022 · 3 comments · Fixed by #394
Closed

[BUG] Release fails due to dependency conflict #393

Nukesor opened this issue Nov 21, 2022 · 3 comments · Fixed by #394
Assignees

Comments

@Nukesor
Copy link
Owner

Nukesor commented Nov 21, 2022

A dependency mismatch came up during the publishing process of the v0.21.0-rc.0 of pueue-lib:
Ping @mjpieters

cargo release -p pueue-lib
warning: disabled by user, skipping pueue v3.0.0-rc.0 despite being unpublished
  Publishing pueue-lib
    Updating crates.io index
   Packaging pueue-lib v0.21.0-rc.0 (/home/nuke/repos/tools/pueue/lib)
   Verifying pueue-lib v0.21.0-rc.0 (/home/nuke/repos/tools/pueue/lib)
error: failed to verify package tarball

Caused by:
  failed to select a version for `memchr`.
      ... required by package `darwin-libproc v0.2.0`
      ... which satisfies dependency `darwin-libproc = "^0.2.0"` of package `pueue-lib v0.21.0-rc.0 (/home/nuke/repos/tools/pueue/target/package/pueue-lib-0.21.0-rc.0)`
  versions that meet the requirements `~2.3` are: 2.3.4, 2.3.3, 2.3.2, 2.3.0

  all possible versions conflict with previously selected packages.

    previously selected package `memchr v2.4.1`
      ... which satisfies dependency `memchr = "^2.4.1"` of package `rev_buf_reader v0.3.0`
      ... which satisfies dependency `rev_buf_reader = "^0.3"` of package `pueue-lib v0.21.0-rc.0 (/home/nuke/repos/tools/pueue/target/package/pueue-lib-0.21.0-rc.0)`

  failed to select a version for `memchr` which could resolve this conflict

Seems like we're running into the same issue as heim-rs/darwin-libproc#3

The Cargo.toml is rewritten as described in rust-lang/cargo#4030 and looks like this:

Example
# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
#
# When uploading crates to the registry Cargo will automatically
# "normalize" Cargo.toml files for maximal compatibility
# with all versions of Cargo and also rewrite `path` dependencies
# to registry (e.g., crates.io) dependencies.
#
# If you are reading this file be aware that the original Cargo.toml
# will likely look very different (and much more reasonable).
# See Cargo.toml.orig for the original contents.

[package]
edition = "2021"
rust-version = "1.63"
name = "pueue-lib"
version = "0.21.0-rc.0"
authors = ["Arne Beer <[email protected]>"]
description = "The shared library to work with the Pueue client and daemon."
homepage = "https://github.com/nukesor/pueue"
readme = "README.md"
keywords = ["pueue"]
license = "MIT"
repository = "https://github.com/nukesor/pueue"

[dependencies.anyhow]
version = "1"

[dependencies.async-trait]
version = "0.1"

[dependencies.byteorder]
version = "1"

[dependencies.chrono]
version = "0.4"
features = ["serde"]

[dependencies.command-group]
version = "1.0.8"

[dependencies.dirs]
version = "4"

[dependencies.log]
version = "0.4"

[dependencies.rand]
version = "0.8"

[dependencies.rcgen]
version = "0.9"

[dependencies.rev_buf_reader]
version = "0.3"

[dependencies.rustls]
version = "0.20"
default-features = false

[dependencies.rustls-pemfile]
version = "1"

[dependencies.serde]
version = "1"

[dependencies.serde_cbor]
version = "0.11"

[dependencies.serde_derive]
version = "1"

[dependencies.serde_json]
version = "1"

[dependencies.serde_yaml]
version = "0.9"

[dependencies.shellexpand]
version = "2.1"

[dependencies.snap]
version = "1"

[dependencies.strum]
version = "0.24"

[dependencies.strum_macros]
version = "0.24"

[dependencies.thiserror]
version = "1"

[dependencies.tokio]
version = "1"
features = [
  "rt-multi-thread",
  "time",
  "io-std",
  "macros",
  "net",
  "io-util",
]

[dependencies.tokio-rustls]
version = "0.23"
default-features = false

[dev-dependencies.anyhow]
version = "1"

[dev-dependencies.better-panic]
version = "0.3"

[dev-dependencies.portpicker]
version = "0.1"

[dev-dependencies.pretty_assertions]
version = "1"

[dev-dependencies.tempdir]
version = "0.3"

[dev-dependencies.tokio]
version = "1"
features = ["time"]

[target."cfg(target_os = \"linux\")".dependencies.procfs]
version = "0.14.1"
default-features = false

[target."cfg(target_vendor = \"apple\")".dependencies.libproc]
version = "0.12.0"

[target."cfg(target_vendor = \"apple\")".dev-dependencies.darwin-libproc]
version = "0.2.0"

[target."cfg(unix)".dependencies.whoami]
version = "1"

[target."cfg(windows)".dependencies.winapi]
version = "0.3"
features = [
  "tlhelp32",
  "handleapi",
  "processthreadsapi",
  "minwindef",
  "impl-default",
]

[badges.maintenance]
status = "actively-developed"

It definitely tags darwin-libproc as a dev-dependency:

[target."cfg(target_vendor = \"apple\")".dev-dependencies.darwin-libproc]
version = "0.2.0"

As expected, the tagged version 0.2.0 is used and it seems that dev-dependencies are still considered when checking the release tarball.
This issue (rust-lang/cargo#4242) has a long and detailed discussion about this.
The discussion over here is quite interesting on why dev-dependencies should work: rust-lang/cargo#4242 (comment)

From what I gathered in this thread, it might work to remove the version tag from the dependency in question, which could result in this specific dependency no longer showing up in the generated Cargo.toml.

@Nukesor
Copy link
Owner Author

Nukesor commented Nov 21, 2022

Looks like that indeed worked.
The new generated Cargo.toml no longer contains the crate:

[target."cfg(target_vendor = \"apple\")".dependencies.libproc]
version = "0.12.0"

[target."cfg(target_vendor = \"apple\")".dev-dependencies]

[target."cfg(unix)".dependencies.whoami]
version = "1"

Looks a bit funky but seems to work.

@Nukesor
Copy link
Owner Author

Nukesor commented Nov 21, 2022

Well, any automated test runners will fail for the macos build, if they don't use the Cargo.toml.orig. But I guess this is the only viable way until we find a better replacement for the darwin-libproc library.

@mjpieters
Copy link
Contributor

Another reason to push forward with my PR for libproc-rs then! That PR makes it possible to swap out darwin-libproc altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants