zellij
zellij copied to clipboard
Error installing 0.31.0 with cargo install
Thank you for taking the time to file this issue! Please follow the instructions and fill in the missing parts below the instructions, if it is meaningful. Try to be brief and concise.
Basic information
zellij --version
: n/a not installed, trying to install zellij v0.31.0
stty size
: 55 72
uname -av
or ver
(Windows): Linux pop-os 5.17.15-76051715-generic #202206141358~1655919116~22.04~1db9e34 SMP PREEMPT Wed Jun 22 19 x86_64 x86_64 x86_64 GNU/Linux
List of programs you interact with as, PROGRAM --version
: output cropped meaningful, for example:
nvim --version
: NVIM v0.5.0-dev+1299-g1c2e504d5 (used the appimage release)
alacritty --version
: alacritty 0.7.2 (5ac8060b)
alacritty 0.10.1-rc1
Further information Reproduction steps, noticeable behavior, related issues, etc
Running cargo install
received the following error:
error: couldn't read /home/cognitivegears/.cargo/registry/src/github.com-1ecc6299db9ec823/termwiz-0.16.0/src/tmux_cc/tmux_cc/tmux.pest: No such file or directory (os error 2)
--> /home/cognitivegears/.cargo/registry/src/github.com-1ecc6299db9ec823/termwiz-0.16.0/src/tmux_cc/mod.rs:12:14
|
12 | #[derive(Parser)]
| ^^^^^^
|
= note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info)
Although this looks like an error in termwiz, reporting here too in case a different version is needed, etc.
@cognitivegears,
Thank you for the report,
do you mind running rustc --version
and cargo --version
and then reporting its output?
Sure thing, thanks!
rustc --version
:
rustc 1.61.0 (fe5b13d68 2022-05-18)
cargo --version
:
cargo 1.61.0 (a028ae4 2022-04-29)
As a side note, cargo-binstall
did install zellij fine. Also, I had also installed a previous version of zellij (sorry, don't remember which version now) with cargo install
successfully, this was an upgrade.
Also, just to try it, since I was a little out of date I tried updating rustc and cargo to the latest, but I'm still getting the same issue when trying to run cargo install. Now I have:
rustc --version
:
rustc 1.62.1 (e092d0b6b 2022-07-16)
cargo --version
:
cargo 1.62.1 (a748cf5a3 2022-06-08)
I'm also hitting this exact error, it's due to a version specification in the dependencies you can fix it with cargo install --fixed zellij
I'm also hitting this exact error, it's due to a version specification in the dependencies you can fix it with
cargo install --fixed zellij
@jscarrott - thanks for mentioning this! Could you say more about this or maybe link to some place where I can read more about it?
So in a dependency specification somewhere there is a version specification that matches more than one version of the dependency. i.e. "foo = 1.0" matches 1.0.x. Normally when you run a cargo build a concrete version is decided once and written into your cargo.lock file. Cargo install by default doesn't use the lock file and so will resolve the dependency version again which can select a new version which in this case is broken. Building with cargo install --fixed just uses the lock file committed into the repository.
I am a little too busy at the moment to work out exactly which dependency is causing the issue.
You can reproduce this by just deleting the lock file in the repo before running a build.
Just a quick note - I believe the option to cargo may be --locked
, at least on my system. I can confirm that this command worked for me:
cargo install --locked --force zellij
(the --force
was needed because I had previously used cargo-binstall
to install zellij)
Here is some more discussion on cargo install
's default behaviour:
https://github.com/rust-lang/cargo/issues/7169
Some other projects are recommending by default to install through cargo install --locked
, instead of cargo install
, should we recommend that as well?
Holy cow. I definitely did not know this. I'm honestly a little bit surprised we're just hitting this issue now. Yes @a-kenji - I agree. We should definitely recommend it.
Holy cow. I definitely did not know this. I'm honestly a little bit surprised we're just hitting this issue now. Yes @a-kenji - I agree. We should definitely recommend it.
Agreed, I am also quite surprised!
Ah yeah it is indeed --locked that was me somehow transcribing what I had just typed wrong
Seems there's a fix for this issue, closing it.