How to depend on a rust crate in a git repo's submodule?

help
1

I'm struggling to consume a git repo as a crate. I've posted to StackOverflow but haven't found an answer there for a few days. Lots of details over there. Can anyone here help?

How to depend on a rust crate in a git repo's submodule? - Stack Overflow

Thanks.

2

It sounds like you want to use a path dependency.

Say your main crate is under crates/my-app/ and the submodule is checked out as vendor/another-crate/, you would add the following to your Cargo.toml file:

[dependencies]
another-crate = { path = "../vendor/another-crate" }

The other crate is included in your repository as a git submodule so you know it'll always be available on the local filesystem.

1 Like
3

You would hope :sweat_smile:

Git submodules are kind of an afterthought addendum to git repos. When you clone a git repo, all you have of its submodules is a pointer saying where the submodule repo is located, and you then have to specifically ask to also clone the submodule contents. If the submodules have submodules, repeat recursively, though at least there's a command to automatically do a git command for all transitive submodules.

dep = { git = "..." } is a git dependency. It will clone the git repository at the specified url and pick up any package available in the workspace defined by the root Cargo.toml. (Any mentioned in [workspace].members or as a local path dependency of any crate in the workspace.)

dep = { path = "..." } is a path dependency. It will use the package at the specified path on your computer's filesystem.

I would not be surprised if git dependencies solely do a clone and do not initialize submodules. Additionally, I do not believe that there is any way to specify to use a package from a git repository which is not discoverable from a root Cargo.toml, other than to clone the repo yourself and use a path dependency.

Depending on how complex the setup, you might even be better served by setting up a custom registry rather than try to use interesting git dependencies. But on the other hand, your local filesystem is the simplest, most trivial registry to set up and use.

1 Like
4

Cargo recursively checks out submodules for git deps.

4 Likes
5

Thanks. I'll try that. But I wasn't using submodules and really didn't want to start using them. I was hoping to just use cargo's built-in git crate support.

6

It's not working. Here's my latest effort:
AArnott/my-zcash-sync (github.com)

You can see it's minimal. I just want to get cargo check to pass. I added a bunch of patch dependencies to match those set in the zwallet repo to get passed dependency resolution errors. But now I get a few compile errors like the one below. I don't know what to make of it because cargo check passes when I run it directly in the crate that I ultimately want to consume.

error[E0277]: the trait bound `OrchardDomain: zcash_note_encryption::Domain` is not satisfied
   --> external/zwallet/native/zcash-sync/src/sync/trial_decrypt.rs:76:6
    |
76  | impl ShieldedOutput<OrchardDomain, COMPACT_NOTE_SIZE> for CompactOutputBytes {
    |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `zcash_note_encryption::Domain` is not implemented for `OrchardDomain`
    |
help: trait impl with same name found
   --> /home/andrew/git/my-zcash-sync/external/zwallet/orchard/src/note_encryption.rs:112:1
    |
112 | impl Domain for OrchardDomain {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `zcash_note_encryption` are being used?
    = help: the trait `zcash_note_encryption::Domain` is implemented for `SaplingDomain<P>`
note: required by a bound in `ShieldedOutput`
   --> /home/andrew/.cargo/git/checkouts/librustzcash-9caebde005fcca12/e2fe0b8/components/zcash_note_encryption/src/lib.rs:329:29
    |
329 | pub trait ShieldedOutput<D: Domain, const CIPHERTEXT_SIZE: usize> {
    |                             ^^^^^^ required by this bound in `ShieldedOutput`
7

Given the error seems to come from two different versions of the same crate being present when built from your workspace but not theirs, it sounds like you haven't fully accurately reproduced all of the relevant dependency patches.

Running cargo tree from both locations will enable you to compare the dependency tree resolution to identify where it differs and try to resolve that difference.

1 Like