[Bug]: cargo shuttle init: Could not query the latest version of shuttle-runtime
0atman opened this issue · 15 comments
What happened?
While running cargo shuttle init
, after selecting the web framework it panics with Could not query the latest version of shuttle-runtime
Version
cargo-shuttle 0.14.0 (but I have also tested 0.13.0 with the same problem)
Which operating systems are you seeing the problem on?
Linux
Which CPU architectures are you seeing the problem on?
ARM64
(specifically I'm running asahi linux on mac mini)
6.2.0-asahi-11-1-edge-ARCH aarch64 GNU/Linux
Relevant log output
# Short backtrace
thread 'main' panicked at 'Could not query the latest version of shuttle-runtime', cargo-shuttle/src/init.rs:985:33
stack backtrace:
0: rust_begin_unwind
at /rustc/2c[...]74/library/std/src/panicking.rs:575:5
1: core::panicking::panic_fmt
at /rustc/2c[...]74/library/core/src/panicking.rs:64:14
2: cargo_shuttle::init::get_latest_dependency_version
3: cargo_shuttle::init::cargo_shuttle_init
4: cargo_shuttle::Shuttle::run::{{closure}}
5: cargo_shuttle::main::{{closure}}
6: tokio::runtime::park::CachedParkThread::block_on
7: tokio::runtime::runtime::Runtime::block_on
8: cargo_shuttle::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
# Full backtrace and context
❯ RUST_BACKTRACE=full cargo shuttle init
How do you want to name your project? It will be hosted at ${project_name}.shuttleapp.rs.
✔ Project name · tststststs
Where should we create this project?
✔ Directory · tstststs
Shuttle works with a range of web frameworks. Which one do you want to use?
· axum
thread 'main' panicked at 'Could not query the latest version of shuttle-runtime', /home/oatman/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-shuttle-0.14.0/src/init.rs:985:33
stack backtrace:
0: 0xaaab01446a1c - std::backtrace_rs::backtrace::libunwind::trace::ha0deed5dc23ee505
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0xaaab01446a1c - std::backtrace_rs::backtrace::trace_unsynchronized::h924cfead2aff5443
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0xaaab01446a1c - std::sys_common::backtrace::_print_fmt::h199f3cb0058a3585
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/sys_common/backtrace.rs:65:5
3: 0xaaab01446a1c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h862f17917f2c8213
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/sys_common/backtrace.rs:44:22
4: 0xaaab0146f424 - core::fmt::write::h7f12d187fe61b77e
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/core/src/fmt/mod.rs:1254:17
5: 0xaaab0144189c - std::io::Write::write_fmt::h6048f25565582382
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/io/mod.rs:1698:15
6: 0xaaab01446864 - std::sys_common::backtrace::_print::hd38d7361d7d2a4e1
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/sys_common/backtrace.rs:47:5
7: 0xaaab01446864 - std::sys_common::backtrace::print::h7e4a2ed892f5173f
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/sys_common/backtrace.rs:34:9
8: 0xaaab014485d4 - std::panicking::default_hook::{{closure}}::ha8056671b69510e2
9: 0xaaab014483c4 - std::panicking::default_hook::h406699bc7969c49c
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:288:9
10: 0xaaab01448a7c - std::panicking::rust_panic_with_hook::he2bac1390d9d1f8a
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:691:13
11: 0xaaab0144896c - std::panicking::begin_panic_handler::{{closure}}::h9044bbe96c2c9391
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:582:13
12: 0xaaab01446e48 - std::sys_common::backtrace::__rust_end_short_backtrace::h5c73f57261750ceb
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/sys_common/backtrace.rs:150:18
13: 0xaaab014486f0 - rust_begin_unwind
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:578:5
14: 0xaaab00767770 - core::panicking::panic_fmt::hf5f60a2900cd370d
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/core/src/panicking.rs:67:14
15: 0xaaab009f2160 - cargo_shuttle::init::get_latest_dependency_version::h154a11fb46854cd3
16: 0xaaab009f16b4 - cargo_shuttle::init::cargo_shuttle_init::h21782a8cce89764c
17: 0xaaab008d05a0 - cargo_shuttle::Shuttle::run::{{closure}}::hb077998f0ab5a30d
18: 0xaaab008f190c - tokio::runtime::park::CachedParkThread::block_on::hc969d5cb36ef51b3
19: 0xaaab007fa7fc - tokio::runtime::scheduler::multi_thread::MultiThread::block_on::h7dcc1d5579a2c64a
20: 0xaaab00869bb4 - tokio::runtime::runtime::Runtime::block_on::h4e0c7de1ba0fc8ae
21: 0xaaab00832e78 - cargo_shuttle::main::h285b5bc1aa2e8f75
22: 0xaaab008e40dc - std::sys_common::backtrace::__rust_begin_short_backtrace::h0b34db2bbaa178da
23: 0xaaab007baac8 - std::rt::lang_start::{{closure}}::hdc84d690a6807c4e
24: 0xaaab01437aac - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h5a23cd6a07960a38
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/core/src/ops/function.rs:287:13
25: 0xaaab01437aac - std::panicking::try::do_call::h8ca37b37e4fae4e7
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:485:40
26: 0xaaab01437aac - std::panicking::try::h74252f8f81d27dc4
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:449:19
27: 0xaaab01437aac - std::panic::catch_unwind::ha74244482ee54d1e
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panic.rs:140:14
28: 0xaaab01437aac - std::rt::lang_start_internal::{{closure}}::he25f3312cd172cc2
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/rt.rs:148:48
29: 0xaaab01437aac - std::panicking::try::do_call::h5f3204433e0f8bf6
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:485:40
30: 0xaaab01437aac - std::panicking::try::hcb3971aa1c7de371
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panicking.rs:449:19
31: 0xaaab01437aac - std::panic::catch_unwind::h097a52ed34474c08
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/panic.rs:140:14
32: 0xaaab01437aac - std::rt::lang_start_internal::h6547485790670ccc
at /rustc/c609da59d9fc05b1c7dc879d79700ccd8140b5fc/library/std/src/rt.rs:148:20
33: 0xaaab00832f7c - main
34: 0xffff28f47b80 - <unknown>
35: 0xffff28f47c60 - __libc_start_main
36: 0xaaab00767cf0 - _start
at /build/glibc/src/glibc/csu/../sysdeps/aarch64/start.S:81
37: 0x0 - <unknown>
Duplicate declaration
- I have searched the issues and there are none like this.
I have installed cargo-shuttle
both from source and cargo binstall
no dice
inside the discord walled garden, we are talking about how this seems to be caused by sparse registries not playing well with cargo-edit. I've switched to stable
which I believe shouldn't have sparse enabled, but it's not worked either.
Debugging continues...!
Ah, so sparse registries are enabled by default on nightly? I'm not sure just switching it back to git will fix the bug either, I think the cache would still need to be updated. So I would try the suggestions from discord, running cargo update/upgrade/fetch in a crate which depends on shuttle-runtime v0.14.0. Unfortunately I still haven't reproduced the bug, so I can't test it myself
Trying those now.
I think you might be able to just rustup default nightly
to reproduce it?
I've tested this on both my aarch64 m1 machines, and my x86_64 surface pro, and I think because I always use nightly, this upstream bug happens on all of them, despite switching to stable.
The upstream problem seems to be caused by killercup/cargo-edit#841
The fix recommended in the above, is to add this to your .cargo/config
[registries.crates-io]
protocol = "git"
In my experience, you then ALSO need to warm up the cache, which I can do repeatably with cargo install cargo-shuttle -f
After doing these two, it does indeed fix it, both on stable and on nightly
Thank you for getting to the bottom of this and finding a work-around! For visibility I'll reiterate what I said regarding this issue in our conversation on discord:
We have been planning a refactor of our init function to rather bootstrap projects from templates (e.g. our examples repo). That would resolve this issue as well, since we would no longer rely on cargo-edit
to fetch the latest version. We're about to start on this next week, and it should be good to go within a few weeks. Until them I'll look around for an intermediate solution, and I'll also add your work-around to our docs to minimize the time people need to spend debugging this.
MSRV By Framework, plus notes
- actix
- axum
- 1.60
- rocket
- https://rocket.rs/v0.5-rc/guide/upgrading/#stable-release-channel
- "Our recommendation is to develop locally on the nightly channel but build and deploy for production on the stable channel."
- tide
- ?
- tower
- 1.49.0
- poem
- 1.64.0
- salvo
- 1.59
- serenity
- hyper/warp
- ?
- thruster
- "stable"
The Problem
The biggest problem I see is that Rocket has always (and still does today) recommend nightly
, and many projects have nice-to-have or quality-of-life features that they mention in their documentation, though not as strongly as Rocket. This will mean that a small number of users are using nightly
.
Nightly breaks shuttle init, and once broken it's not obvious how to un-break it, likely you'd have to come here to figure it out.
I look forward to the fix! Thank you for your work, team :-)
Oh, I just realised the beta
channel is 1.70.0, which would break this too.
I just added reproducible fix instructions to my comment here #821 (comment)
Perfect, thanks! One of our contributors has volunteered to help out with the refactor of init
as well, so we should be able to get this resolved soon. 🤞
Yes, it was caused by cargo-edit trying to get_latest_version, so it should be fixed since we no longer rely on that.