https://linen.dev logo
[Bug]: cargo shuttle init: Could not query the lat...
# help
m
Hi folks, I wonder if anyone else has had my problem? Is it because I'm on ARM64, I hope not! https://github.com/shuttle-hq/shuttle/issues/821
k
Hey @many-artist-78130, welcome! So I've seen this twice in the last few days, once was in our CLI since
cargo-edit
struggled to find the latest version when we had sparse registries enabled. The other was this user report:
I wasn't sure if this was a spurious issue or not, but it looks like this will be a common issue and definitely something we need to fix. Thanks for opening an issue for this!
m
thank you very much! is there a workaround for now, as I am working with @gentle-agency-53651 to produce a tutorial on the 5fh of May, and this is a blocker!
(also hi Ivan!)
k
Yes, we need to do what @rich-fall-99047 from the message linked above did to update the cargo cache, I'm looking for answers for this now
It's late in australia so he's not likely to be able to reply for a while
Have you enabled sparse registries in your .cargo/config, btw?
There might be some things to try in this thread as well: (I can't test this myself since I'm not sure how to reproduce this issue)
Just running
cargo upgrade/update
in any crate might also help
If the above didn't work, running
cargo fetch
() from a crate which depends on shuttle-runtime 0.14 might work
Let me know if the above doesn't work and I'll keep looking. Long term we are planning to refactor init to scaffold from templates (e.g. our examples repo), we're hoping to get started on this next week.
m
super, will try it!
r
cargo install xxx
apparently updates the local registry cache, so I deleted one of the binaries in my
cargo bin
and reinstalled it. Crude, but did the job 😉
I do have sparse registries enabled - I flicked the switch when the Rust team asked people to test it. And then promptly forgot all about it.
m
Thank you for your help, I'm trying to work around it now - how common do you think this will be, will everyone who has sparse registries enabled (ie nightly peeps) hit it?
k
Your report is the second we have received from users, and sparse registries has been around for a while in some form, and stable for ~2 months. So I'm not sure yet, and it seems like it may take some time for this to be fixed upstream. We will look into if there is a good intermediate solution for this until we can implement the refactor.
m
huh I wonder why it's affecting me? ARM64 perhaps?
I'm investigating today, will report back on the issue
❗ BTW I must suggest in the strongest way possible that doing bug reporting inside discord is extremely bad for both you and your users. For example, I tried searching for this bug on github before posting, but I couldn't find the fixes because they were here, inside the walled garden, not on gh issues. This won't scale!
(the
protocol="git"
fix worked for me, documented here https://github.com/shuttle-hq/shuttle/issues/821)
k
I think it's due to sparse registries, as mentioned in the cargo-edit issue from above, I didn't realize that was the default for nightly (although I know it is likely to be default for stable in the future).
Awesome!
m
very awesome, though the cargo edit conversation looks quite relaxed, I worry they'll not fix your upstream problem quickly!
k
Thanks for the feedback, you are absolutely correct and this is a common issue in the rust ecosystem where discord is common. We do try to open issues for bugs reported on discord, but we have not been doing a very good job of this lately. We'll try to improve on this going forward. 🙏
Indeed! 😄 We're likely to finish the refactor of init before it gets fixed upstream, I'd say
m
NICE
any eta on that?
k
We're planning to start it next week during an open-source event we're doing, so it'd likely be a few weeks. We can discuss moving it up, but we do have other issues to iron out.
m
cool
k
In the meantime I will add your work-around to our docs to ensure some visibility for this
m
there's a bit of breathing room before 1.70.0 makes sparse the default
k
Ah, that's coming already in 1.70, cool!
m
> The sparse protocol is currently planned to become the default for crates.io in the 1.70.0 release in a few months.
yeah!
@kind-area-3810 1 June, 2023 1.70.0 will be released 😁
k
We will aim to have this resolved in good time for that, but thanks, we have our deadline 😂
m
hehe
k
By the way, I forgot to mention this, but on the subject of nightly: our
deployer
containers that build your project on our infrastructure do no support nightly. They are currently on rustc 1.68, and we try to keep them as close to the latest release as we can, but these images are built for each release. We plan to support choosing the rust version, also nightly, in the future. It's going to be a little while, likely a few months, but we are starting work on a refactor of how we build users projects next week that should make supporting things like that (and other native dependencies you may need to compile your project) a lot easier.
So you can use nightly locally, but if you use unstable language features it will fail to compile in deployment.
m
oh interesting! that makes sense
If I were you I'd also add a CI pipeline that builds on nightly, to get a heads-up on upcoming breaking changes
this would have broken in febuary, I guess?
quite a noisy pipeline ofc
axum and actix test their CI on nightly, I see in my research, for instance
I'm putting together some notes on nightly compatibility, will update the issue with my findings soon
k
Thanks! That's a good suggestion, and it is indeed common. I'll be interested to see your findings on this.
m
write-up here, I'm going to continue testing shuttle while using the git fix https://github.com/shuttle-hq/shuttle/issues/821
thanks so much @kind-area-3810 🎉
k
No worries, thanks for the msrv research and debugging!
3 Views