file not found for module montgomery

[ghost]

This might be more user error than legitimate issue, but when trying to install aardwolf, I get this error:

` Compiling ring v0.11.0
Compiling r2d2-diesel v0.99.0
error[E0583]: file not found for module montgomery
--> /Users/ghost/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic/arithmetic.rs:15:9
|
15 | pub mod montgomery;
| ^^^^^^^^^^
|
= help: name the file either arithmetic/montgomery.rs or arithmetic/montgomery/mod.rs inside the directory "/Users/ghost/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic"

error: aborting due to previous error

error: Could not compile ring.
warning: build failed, waiting for other jobs to finish...
error: build failed
`
However, arithmetic/montgomery.rs exists.

It looks like this is a known issue with a fix coming, but I don't have a solid enough grasp on Rust to fully understand what the issue is, exactly, or if there's a workaround in the meantime.

[asonix]

That's because the ring library doesn't use a proper directory structure, and it broke with versions of rust nightly newer that December 21st. Use an older version of rust and you should be okay. The Rocket developer is already aware and making a solution

[ghost]

thanks for the quick and simple explanation, @asonix!

[BanjoFox]

Wait... I thought we Pinned the rocket version?

[BanjoFox]

In fact we did...
file: rust-toolchain

I am going to apply this update to the INSTALL.MD

[asonix]

Rocket works on the latest nightly again

[BanjoFox]

Thanks @asonix - still wondering if it makes sense to pin a known-working nightly.

[KD0BPV]

Yes, it still makes sense to pin the tool chain version. It'll prevent a lot of "Uh... It works for me"-type problems; specifically those caused by someone unwittingly trying to build the software without paying any attention to what version of the toolchain they are using. As for how Rocket suddenly got updated to a version that the pinned toolchain at the time stopped working, I'm not sure. It shouldn't have happened, because of the Cargo.lock file. The mostly likely explanation I can come up with is that we maybe didn't make the version specific enough in the Cargo.toml. Some important notes: [Cargo Manifest: The Version Field](https://doc.rust-lang.org/cargo/reference/ manifest.html#the-version-field) [Cargo Manifest: Specifying Dependencies](https://doc.rust-lang.org/cargo/ reference/specifying-dependencies.html)

…

On Saturday, January 13, 2018 2:01:58 PM CST BanjoFox wrote: Thanks @asonix - still wondering if it makes sense to pin a known-working nightly.

[BanjoFox]

Actually it -really- isn't a mystery.
It's because we have specific instructions in our INSTALL.md that used to state:

$ rustup toolchain install nightly

Therefore anyone running through the INSTALL.md, which is very well written (props!), they will install whatever is nightly for them at the time. That is why I made a direct commit to make it

$ rustup toolchain install nightly-2017-12-18

[KD0BPV]

Yes, but that's over-riden by the rust-toolchain file. It pins the version of the toolchain to what is specified in that file. As long as they're using cargo, cargo will automatically download, install, and use the pinned toolchain version, regardless of what version they have set as default or have installed.

…

On 1/13/2018 6:36 PM, BanjoFox wrote: Actually it -really- isn't a mystery. It's because we have specific instructions in our INSTALL.md that used to state: |$ rustup toolchain install nightly| Therefore anyone running through the INSTALL.md, which is very well written (props!), they will install whatever is nightly for them at the time. That is why I made a direct commit to make it |$ rustup toolchain install nightly-2017-12-18| — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEdfrZCpJnjNVNPVba8UxLfGgtzdL0Cbks5tKUwYgaJpZM4RV4HD>.

[BanjoFox]

So far I have been able to replicate this bug a few times.
Not sure what is going on, but when I -manually- set the nightly build (12-18-2017 I think?) in the README.md it seems to resolve the problems..

Not something to worry about now, but I will keep this in mind, and leave the issue open :)
This way people can reference it, and I will remember, in the event that people have problems.

[BanjoFox]

Newer versions of Rust Nightly seem to be working appropriately.
Closing this issue.