Problem with renaming dependencies

help
1

Hi!

Sorry if this has been answered before but I really could not find anything.

I have two cargo projects, lets call them "the_bin" and "rename_deps".

"rename_deps" has dependencies on multipel versions of the same crate,
embedded-hal v0.2 and optionally embedded-hal v1 (1.0.0-alpha.9 in this case, have not yet updated, but that is beside the point).

[package]
name = "rename_deps"
version = "0.1.0"
edition = "2021"
publish = ["gitea"]

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[features]
e-hal-v1 = ["embedded-hal"]

[dependencies]
embedded-hal = { version = "=1.0.0-alpha.9", optional = true }
embedded-hal-0-2 = { package = "embedded-hal", version = "0.2.7", features = ["unproven"] }

src/lib.rs

pub fn do_things_w_v02_input(_x: impl embedded_hal_0_2::digital::v2::InputPin){ todo!() }

// Not used
#[cfg(feature = "e-hal-v1")]
pub fn do_things_w_v1_input(_x: impl embedded_hal::digital::InputPin){ todo!() }

Compiling "rename_deps" works fine. cargo c && argo c --all-features completes successfully.

I create my new project "the_bin" which depends on "rename_deps" with default features (not embedded-hal v1) and directly on embedded-hal v0.2:

[package]
name = "the_bin"
version = "0.1.0"
edition = "2021"

[dependencies]
rename_deps = { path = "local path" } # <--- This is a local path on my machine
#rename_deps = { version = "0.1.0", registry = "gitea" } # <-- Not yet
embedded-hal = { package = "embedded-hal", version = "0.2.7" }

This too works fine. (notice the local path to "rename_deps".

I then publish this crate to my private registry(gitea), the pre-publish check-thing succeeds and all is fine. Then after
updating the dependency in Cargo.toml to:

rename_deps = { version = "0.1.0", registry = "gitea" }

it won't compile:

  Downloaded rename_deps v0.1.0 (registry `gitea`)
  Downloaded 1 crate (1.0 KB) in 0.17s
   Compiling rename_deps v0.1.0 (registry `gitea`)
error[E0433]: failed to resolve: use of undeclared crate or module `embedded_hal_0_2`
 --> /home/albin/.cargo/registry/src/my-very-secret-gitea-registry/rename_deps-0.1.0/src/lib.rs:2:39
  |
2 | pub fn do_things_w_v02_input(_x: impl embedded_hal_0_2::digital::v2::InputPin){
  |                                       ^^^^^^^^^^^^^^^^ use of undeclared crate or module `embedded_hal_0_2`
  |
help: there is a crate or module with a similar name
  |
2 | pub fn do_things_w_v02_input(_x: impl embedded_hal::digital::v2::InputPin){
  |                                       ~~~~~~~~~~~~
help: consider importing this module
  |
2 + use embedded_hal::digital::v2;
  |
help: if you import `v2`, refer to it directly
  |
2 - pub fn do_things_w_v02_input(_x: impl embedded_hal_0_2::digital::v2::InputPin){
2 + pub fn do_things_w_v02_input(_x: impl v2::InputPin){
  |

For more information about this error, try `rustc --explain E0433`.
error: could not compile `rename_deps` (lib) due to previous error

for some reason "rename_deps" fails to compile, the renamed dep: embedded_hal_0_2 can not be found.

Am I doing anything wrong :slight_smile: ? Is this a rust issue or should I post this question at gitea the service I use for my private registry. I am fine with sharing this code if it helps :slight_smile:
I could publish rename_deps to the regular crates.io just to test but that feels a bit wasteful for a test.

/Albin

2

Tested with

$ rustc --version
rustc 1.75.0 (82e1608df 2023-12-21)

and

$ rustc --version
rustc 1.79.0 (129f3b996 2024-06-10)

same thing

3

Have you tried importing rename_deps from git instead of from a path or private registry? Did it work same as importing it via a local path? I don't believe it is an issue with your registry as all Cargo does is download the source from it and that looks like it worked fine. Only once Cargo tried to compile the dependency an error is encountered.

4

Thank you, I will give that a try

5

Yes using a git dependency works fine.

6

It looks like the dependency rename isn't happening for some reason, since embedded_hal:: exists. If you enable the "e-hal-v1" feature, I expect you'll get an error from two dependencies with the same crate name.

The first thing I'd do personally is check the Cargo.toml in the unpacked registry (.cargo/registry/src/my-very-secret-gitea-registry/rename_deps-0.1.0/Cargo.toml) to see if it's been materially changed by the publish process; multiple fixups are applied, and that might be what's breaking the dependency rename. If the manifest there is broken, then it's probably an issue with the custom registry. If the manifest is fine / a path dependency to that path works, then it's probably an issue with Cargo's custom registry support.

This indicator isn't a complete given, but it's a good indicator of where to look first. At the worst, the gitea registry developers are better equipped to diagnose where the issue is than we are. If you want to rule out one other potential step where the issue could lie, check the .crate produced by cargo package — it's just a gzipped archive IIRC and holds the packaged crate before the registry sees it and does its own manipulation.

Style thing: use "dep:embedded-hal" when you have a feature enable an optional dependency when the way to enable use of the dependency is that feature. Using this syntax removes the implicit feature that is created by the optional dependency.

1 Like
7

This is what is produced by cargo package (minus comments) and it is identical with .cargo/registry/src/my-very-secret-gitea-registry/rename_deps-0.1.0/Cargo.toml

[package]
edition = "2021"
name = "rename_deps"
version = "0.1.0"
publish = ["gitea"]

[dependencies.embedded-hal]
version = "=1.0.0-alpha.9"
optional = true

[dependencies.embedded-hal-0-2]
version = "0.2.7"
features = ["unproven"]
package = "embedded-hal"

[features]
e-hal-v1 = ["embedded-hal"]

Style thing: use "dep:embedded-hal"

Oh, that is good to know. Thanks :slight_smile:

8

Definitely seems like it's a Cargo issue, then. I'm sure the Cargo team would appreciate a bug report, especially if you can minimize it further[1].

  1. Mostly just remove the unused feature/dependency and cfg-excluded code, if they aren't required to reproduce the issue; maybe use a less heavy crate as the target. Also, mentioning the dependency via just use ::cratename might produce cleaner diagnostics. ↩︎

9

I commented out the non-renamed embedded-hal, published as 0.1.1 and still i get the same error

[features]
#e-hal-v1 = ["embedded-hal"]

[dependencies]
#embedded-hal = { version = "=1.0.0-alpha.9", optional = true }
embedded-hal-0-2 = { package = "embedded-hal", version = "0.2.7", features = ["unproven"] }
10

I will try, thanks a lot for the help so far :slight_smile:

11

Issue filed Fail to compile dependencies which in turn have renamed dependencies · Issue #14148 · rust-lang/cargo · GitHub

1 Like
12

So it was the registry after all. Didn't know Cargo uses the registry for resolution instead of the manifest file downloaded as part of the source code.

13

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.