added toolchain

[nargeslein]

Fixes #issue.

added rust-toolchain file in order to run cargo build outside of docker and use the right version as the docker image would

Test Plan

run cargo buildand rustup showto view that the same settings as by the docker image are used

Release notes

Optionally add notes, suggestions and warnings for the releaser. They will be included in the release changelog.

[mrq1911]

spend 30 minutes rebuilding until I stumbled upon right version 😿

[vkgnosis]

https://rust-lang.github.io/rustup/overrides.html#the-toolchain-file is the documentation for the toolchain file. I'm not sure about this PR because we aren't "pinned to a specific version". We use whatever is the current stable release of Rust like many other projects. We might want to document this in the readme.

[nlordell]

We use whatever is the current stable release of Rust

I like the addition of the toolchain file, as it can express exactly this. We can make the file it specify that the project uses the stable channel, so others know they should have an up-to-date stable Rust.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[nargeslein]

@vkgnosis the docker file does tie it to a specific version which I had tried to mimic in the toolchain file. We spend some time compiling the project during the hackathon until we found out which Rust version needs to be used. I have updated the toolchain file to point to the stable version as @nlordell suggestes :-),

[nargeslein]

have read the CLA Document and I hereby sign the CLA

[nlordell]

the docker file does tie it to a specific version which I had tried to mimic in the toolchain file

Good point. I see rust:1 which should resolve to the latest stable 1.x version according to the Dockerhub reference. This should be the same as stable channel until Rust 2.x comes out.

[vkgnosis]

We spend some time compiling the project during the hackathon until we found out which Rust version needs to be used.

This surprised me because that is what I assume by default when I build a Rust project: it builds with the current stable unless mentioned otherwise. I'm also used to always having the current stable installed and up to date so it hadn't occured to me that someone would try other versions. I'm probably biased by what I'm used to and I can see it might be more confusing for others so I'm fine with the PR.

[nargeslein]

This surprised me because that is what I assume by default when I build a Rust project: it builds with the current stable unless mentioned otherwise. I'm also used to always having the current stable installed and up to date so it hadn't occured to me that someone would try other versions. I'm probably biased by what I'm used to and I can see it might be more confusing for others so I'm fine with the PR.

@vkgnosis many thanks for sharing these information. I am relatively new to Rust and do not use it very often (yet!), this is why I appreciate these information. Unfortunately my laptop is very slow and the first compilation took a while. Do you have any advice on a hardware setup for me? E.g. what are you using if I may ask. Thanks.

[vkgnosis]

Unfortunately this Rust project is slow to build and there is no single solution. Rust in general is slow to build but we also have a large number of dependencies.
There are some things you can do speed up compilation locally that you can find through internet searches or by asking in some of the rust communities . Things like https://endler.dev/2020/rust-compile-times/ and https://nnethercote.github.io/perf-book/compile-times.html . Although these might also be confusing to a rust beginner.
To get large speed ups we as the developers of the project probably have to invest more time reducing dependencies and slow to compile code etc.

[codecov-commenter]

Codecov Report

Merging #166 (22f97ad) into main (3011d69) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #166      +/-   ##
==========================================
+ Coverage   64.55%   64.57%   +0.02%     
==========================================
  Files         185      185              
  Lines       38602    38602              
==========================================
+ Hits        24920    24928       +8     
+ Misses      13682    13674       -8     

[nlordell]

Hmm... Looks like there are CLA issues. Any chance you could rebase/squash this commit using a user.email that matches your GitHub user? I think the issue is:

Narges seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

Sorry for the inconvenience!

[nargeslein]

Hmm... Looks like there are CLA issues. Any chance you could rebase/squash this commit using a user.email that matches your GitHub user? I think the issue is:

Narges seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

Sorry for the inconvenience!

Hello @nlordell many thanks for following up! I had tried to fix it without success. I will try rebase/squash. Thanks for the support.

[nargeslein]

Hello @nlordell, @vkgnosis I think I managed to clean up the commits by rebasing/squashing after some fiddling around. I hope it's fine now :-)

[mrq1911]

We spend some time compiling the project during the hackathon until we found out which Rust version needs to be used.

This surprised me because that is what I assume by default when I build a Rust project: it builds with the current stable unless mentioned otherwise. I'm also used to always having the current stable installed and up to date so it hadn't occured to me that someone would try other versions. I'm probably biased by what I'm used to and I can see it might be more confusing for others so I'm fine with the PR.

this always depends on what you have configured as local default toolchain. i am using for most of my projects some recent nightly build, so if your project don't have toolchain defined, cargo will just my default and fail, but if you define your toolchain version, cargo just automatically uses that and it works for every environment (including ci :)

[nlordell]

I think I managed to clean up the commits by rebasing/squashing after some fiddling around.

Looks like it worked! Thanks for the contribution and for bearing with us through our brand new CLA process 😄