JuliaLang
custom JULIAUP_SERVER for normal http server
The current download implementation seems to require the etag header, which usually doesn't exist for regular HTTP servers. I think juliaup should not assume this header exists (but it seems that this etag header is kept track in the channel db)
This leads to the following crash:
JULIAUP_LOG=debug JULIAUP_SERVER=https://mirrors.tuna.tsinghua.edu.cn/julia-releases juliaup add 1.9
[2024-05-03T17:51:06Z INFO juliaup] Parsing command line arguments.
[2024-05-03T17:51:06Z DEBUG reqwest::connect] starting new connection: https://mirrors.tuna.tsinghua.edu.cn/
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::dns] resolving host="mirrors.tuna.tsinghua.edu.cn"
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connecting to 101.6.15.130:443
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connected to 101.6.15.130:443
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::pool] pooling idle connection for ("https", mirrors.tuna.tsinghua.edu.cn)
Installing Julia 1.9.4+0.aarch64.apple.darwin14
[2024-05-03T17:51:06Z DEBUG juliaup::operations] Downloading from url `https://mirrors.tuna.tsinghua.edu.cn/julia-releases/bin/mac/aarch64/1.9/julia-1.9.4-macaarch64.tar.gz`.
[2024-05-03T17:51:06Z DEBUG reqwest::connect] starting new connection: https://mirrors.tuna.tsinghua.edu.cn/
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::dns] resolving host="mirrors.tuna.tsinghua.edu.cn"
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connecting to 101.6.15.130:443
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::connect::http] connected to 101.6.15.130:443
⠁ Well, this is embarrassing.
Juliaup had a problem and crashed. To help us diagnose the problem you can send us a crash report.
We have generated a report file at "/var/folders/zd/5x9t7qz92sx6c38q9yl7qbm00000gp/T/report-e6878051-147c-40b3-9265-5e677ae61cfb.toml". Submit an issue or email with the subject of "Juliaup Crash Report" and include the report as an attachment.
To submit the crash report:
https://github.com/JuliaLang/juliaup
We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.
Thank you kindly!
[2024-05-03T17:51:06Z DEBUG hyper_util::client::legacy::pool] pooling idle connection for ("https", mirrors.tuna.tsinghua.edu.cn)
The crash report:
"name" = "Juliaup"
"operating_system" = "Mac OS 13.2.1 [64-bit]"
"crate_version" = "1.14.8"
"explanation" = """
Panic occurred in file 'src/operations.rs' at line 81
"""
"cause" = "called `Option::unwrap()` on a `None` value"
"method" = "Panic"
"backtrace" = """
0: 0x100f89578 - core::panicking::panic::hcdbd360f66af7955
1: 0x100f89714 - core::option::unwrap_failed::h7f61ccc9834696cb
2: 0x100dfd720 - juliaup::operations::download_extract_sans_parent::hc477128cc7186939
3: 0x100df7188 - juliaup::operations::install_version::hde6db4a2b39cd26d
4: 0x100df106c - juliaup::command_add::run_command_add::h077c95f3e216b4d0
5: 0x100d1802c - juliaup::main::hae29d18c2d32cdf1
6: 0x100d130a4 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd6f133e2356630ee
7: 0x100d20ce8 - _main"""
We use that etag to figure out whether there is a new nightly build available... The official servers we use support this, so is the problem here that some alternative non-official server doesn't? I'm not sure how else we could implement the same functionality...
Would it be possible to assume there are no nightlies if the etag header isn't returned?
One thing we should definitely do is make things not crash if someone doesn't even have the nightly channel installed and is using a server that doesn't support etags. And then maybe if someone is on that we just lose the ability to notify the user about new nightly builds.