what is exact stable version to use to compile CLI?

[dzmitry-lahoda]

I tried several and getting

 subwasm>    = help: add `#![feature(is_terminal)]` to the crate attributes to enable
subwasm> error[E0658]: use of unstable library feature 'is_terminal'
subwasm>   --> /nix/store/jifhrpg273ml35ndyib0k9yqj0kp26vb-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/anstream-0.5.0/src/is_terminal.rs:68:9
subwasm>    |
subwasm> 68 |         std::io::IsTerminal::is_terminal(self)
subwasm>    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

may be specify exact version used in rust-toolchain and/or use same version as paritity does in their docker?

[chevdor]

There is a rust-toolchain file here. The exact version is the stable version at the moment you build.

I just ran a manual test for you:

$ rustup show
rustc 1.73.0 (cc66ad468 2023-10-03)

$ cargo clean
$ cargo build --profile production 

From your output, I am assuming you are using Linux + nix, correct ? Windows has been causing troubles for a while but Mac + Linux should be building just fine.

[dzmitry-lahoda]

hello, thanks.

1.72 and 1.71 on linux does not work. 1.73 work.

thing is that current stable is not what i do. i used exact version of rust per project.

thin is that just stable does not forces anything to update or warn about bad version.

so proposal is hardcode exact version used in toolchain.

as per day to day run. i tried to look at. but saw it was too red. and kind of broken. kind of hard to see if something is green when there is too much red.

thank you, i updated to 1.73. but request still is here - hardcode exact version, better use parity version as they have in dev docker. because you depend a lot on parity codebase.

[chevdor]

I ensure that subwasm builds with the current stable and I cannot test against all the former versions unfortunately.

I do not want to hardcode an exact version as I would have to update that value everytime a new rustc comes out.

as per day to day run. i tried to look at. but saw it was too red. and kind of broken. kind of hard to see if something is green when there is too much red.

The red you see is related to Windows and I removed that check since it has been annoying for a wihle. I am not even sure if there are Windows users, if there are, maybe they can chime in.

If you want to use an older rust version and the current code fails, you could:

• use an older subwasm version
• check/fix what the issue is with an older version is, we'd need to see per case but you'd need string arguments why you are simply not use the latest Rust version

I tested 1.71.0 and it builds just fine btw.

[dzmitry-lahoda]

i used older version and it compiked with 1.71. but it did not worked well with new polkadot.

but that is thing, you assume that all use lates stable, while.most people not. people stick to version and migrate only when needed.

that is how all serious tooling things do. update manually.

parity does that. i suggested to do what parity does. that it.

so we consider to switch away from subwasm now.

[chevdor]

but it did not worked well with new polkadot.

What does it mean? What was the issue ?

[chevdor]

Check the following out, that may help:

• https://github.com/andresilva/nix-polkadot
• https://github.com/andresilva/subwasm/commit/08b9496e9230e410593977dd2396b0917f028f62

[dzmitry-lahoda]

What does it mean? What was the issue ?

we use old subwasm used old polkadot with metadata v14. but new polkadot is v16. so subxt clients we generated from metadata produced by subwasm failed to call tx. so we know that subxt + polkadot-sdk + subwasm must be aligned in our case. my sugession is to align rust version with parity too. they hardcode rust version btw.