[Bug]: cargo shuttle init: Could not query the latest version of shuttle-runtime

[0atman]

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

• [X] I have searched the issues and there are none like this.

[0atman]

I have installed cargo-shuttle both from source and cargo binstall no dice

[0atman]

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...!

[oddgrd]

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

[0atman]

Trying those now.

I think you might be able to just rustup default nightly to reproduce it?

[0atman]

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.

[0atman]

The upstream problem seems to be caused by https://github.com/killercup/cargo-edit/issues/841

[0atman]

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

[oddgrd]

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.

[0atman]

MSRV By Framework, plus notes

• actix
  • 1.59
  • https://github.com/search?q=repo%3Aactix%2Factix-web%20nightly&type=code
• 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
  • 1.53
    • async closures
      • https://github.com/serenity-rs/serenity/blob/46087950bb197817df19f16da0f457202d6f93ca/examples/e05_command_framework/src/main.rs#L265
    • 2024 https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html#looking-forward
• 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 :-)

[0atman]

Oh, I just realised the beta channel is 1.70.0, which would break this too.

[0atman]

I just added reproducible fix instructions to my comment here https://github.com/shuttle-hq/shuttle/issues/821#issuecomment-1525317860

[oddgrd]

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. :crossed_fingers:

[0atman]

Wonderful news! Thanks to everyone who is helping out :tada:

My extremely scientific poll of my audience suggest that this fix could improve the lives of 19% of your potential users!

[jonaro00]

@oddgrd can this be closed now? Not sure if the problems that @iamwacko referred to here are solved.

[oddgrd]

Yes, it was caused by cargo-edit trying to get_latest_version, so it should be fixed since we no longer rely on that.