New versions of bender can deal with a single package potentially being sourced from different repos. In this case, bender update gives the user the choice which repo+commit should be used.
I encountered a case where a single package had 3 possible repo sources/commits across the dependency tree: Two dependencies pointed to two different repos, and the Bender.lock file had a third repo listed. I suspect the issue is actually not with having 3+ remotes to choose from, but having a remote that is only specified in Bender.lock (without also hardcoding that as an override in Bender.local).
This is the output when resolving the package in question (with RUST_BACKTRACE=full):
Dependency requirements conflict with each other on dependency hwpe-stream.
- package neureka requires 1fc7f05 at https://github.com/da-gazzi/hwpe-stream.git
- package hci requires ^1.8.0 (1.8.0 <= x < 2.0.0) at https://github.com/pulp-platform/hwpe-stream.git
The previous lockfile required 7e1dffc49df39d7d735f8dd47b185ebd8d556e76 at https://github.com/mosaic-soc/hwpe-stream.git.
To resolve this conflict manually, select a revision for hwpe-stream among:
0) 7e1dffc49df39d7d735f8dd47b185ebd8d556e76 at https://github.com/mosaic-soc/hwpe-stream.git
1) 1fc7f05 at https://github.com/da-gazzi/hwpe-stream.git
2) ^1.8.0 at https://github.com/pulp-platform/hwpe-stream.git
Enter a number or hit enter to abort: 0
thread 'main' (3481209) panicked at /Users/georg/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bender-0.31.0/src/resolver.rs:953:88:
called `Option::unwrap()` on a `None` value
stack backtrace:
0: 0x1050af7a0 - <<std[bb513d90a5cee88a]::sys::backtrace::BacktraceLock>::print::DisplayBacktrace as core[f63e075e1375d836]::fmt::Display>::fmt
1: 0x1050c5b04 - core[f63e075e1375d836]::fmt::write
2: 0x1050b6158 - <std[bb513d90a5cee88a]::sys::stdio::unix::Stderr as std[bb513d90a5cee88a]::io::Write>::write_fmt
3: 0x105093958 - std[bb513d90a5cee88a]::panicking::default_hook::{closure#0}
4: 0x1050a7c50 - std[bb513d90a5cee88a]::panicking::default_hook
5: 0x1050a7f78 - std[bb513d90a5cee88a]::panicking::panic_with_hook
6: 0x105093a30 - std[bb513d90a5cee88a]::panicking::panic_handler::{closure#0}
7: 0x10508aeac - std[bb513d90a5cee88a]::sys::backtrace::__rust_end_short_backtrace::<std[bb513d90a5cee88a]::panicking::panic_handler::{closure#0}, !>
8: 0x105094288 - __rustc[b7974e8690430dd9]::rust_begin_unwind
9: 0x1050fb114 - core[f63e075e1375d836]::panicking::panic_fmt
10: 0x1050fb0ec - core[f63e075e1375d836]::panicking::panic
11: 0x1050faefc - core[f63e075e1375d836]::option::unwrap_failed
12: 0x104da47c4 - bender::resolver::DependencyResolver::impose_dep::h8cbb410062f2d6e5
13: 0x104da91c0 - bender::resolver::DependencyResolver::resolve::h56ddb2d6a893447a
14: 0x104da157c - bender::cmd::update::run_plain::hdc66087ee1414f30
15: 0x104da116c - bender::cmd::update::run::hbd0b81f534cbccf9
16: 0x104e37830 - bender::cli::main::hd51b047fa74cf6a7
17: 0x104c18a04 - bender::main::hd990ac24bbddfb86
18: 0x104c18968 - std::sys::backtrace::__rust_begin_short_backtrace::h8b57b868835a35df
19: 0x104c18950 - std::rt::lang_start::{{closure}}::ha16eae81b356de0b
20: 0x1050a6720 - std[bb513d90a5cee88a]::rt::lang_start_internal
21: 0x104c18b68 - _main
If it helps, I can try to reproduce the issue with a set of toy repos that recreate the part of the dependency tree that appears to have caused the problem.
New versions of
bendercan deal with a single package potentially being sourced from different repos. In this case,bender updategives the user the choice which repo+commit should be used.I encountered a case where a single package had 3 possible repo sources/commits across the dependency tree: Two dependencies pointed to two different repos, and the
Bender.lockfile had a third repo listed. I suspect the issue is actually not with having 3+ remotes to choose from, but having a remote that is only specified inBender.lock(without also hardcoding that as an override inBender.local).This is the output when resolving the package in question (with
RUST_BACKTRACE=full):If it helps, I can try to reproduce the issue with a set of toy repos that recreate the part of the dependency tree that appears to have caused the problem.