During deployment, restart download if there was a (network) failure

[Irvise]

Checklist

• I've included the output of alr version.
• I've included complete steps to reproduce my issue.

Describe the feature
While doing an alr build of a project with a new dependency, Alire automatically downloads the dependency as expected. However, due to the (my current) lack of a stable internet connection, the (my) download fails. I would be nice if the curl command that Alire uses to download packages could be updated to allow for the restart of the download where it previously had failed. This would mean that if 15% of a package had been downloaded before the connection failed, when a new alr build/deployment takes place, the download would start back at 15% instead from 0.

Basically, the command (see below for more context) Command ["curl", "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gnatprove-14.1.0-1/gnatprove-x86_64-linux-14.1.0-1.tar.gz", "--location", "--progress-bar", "--output", "/home/fernando/.local/share/alire/releases/alr-cutu.tmp/gnatprove-x86_64-linux-14.1.0-1.tar.gz"] could use the -C flag (see this StackOverflow thread) in order to resume the download.

Expected Behavior
This is basically the issue that I am currently having

fernando@localhost:~/Build/wolfssl/wrapper/Ada> alr build
ⓘ Synchronizing workspace...
Dependencies automatically updated as follows:                           

   New solution is complete.
   No changes between former and new solution.
ⓘ Deploying gnatprove=14.1.1...
###############                                                                                           15.2%curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

error: Command ["curl", "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gnatprove-14.1.0-1/gnatprove-x86_64-linux-14.1.0-1.tar.gz", "--location", "--progress-bar", "--output", "/home/fernando/.local/share/alire/releases/alr-cutu.tmp/gnatprove-x86_64-linux-14.1.0-1.tar.gz"] exited with code 92
fernando@localhost:~/Build/wolfssl/wrapper/Ada> alr build
ⓘ Deploying gnatprove=14.1.1...
##                                                                                           3.2%

alr version

alr version
APPLICATION
alr version:               2.0.1
libalire version:          2.0.1
compilation date:          2024-03-21 11:06:29
compiled with version:     13.2.0

CONFIGURATION
settings folder:           /home/fernando/.config/alire
cache folder:              /home/fernando/.local/share/alire
vault folder:              /home/fernando/.local/share/alire/releases
build folder:              /home/fernando/.local/share/alire/builds
temp folder:               /run/user/1000
force flag:                FALSE
non-interactive flag:      FALSE
community index branch:    stable-1.3.0
compatible index versions: ^1.1 & <=1.3.0
indexes folder:            /home/fernando/.config/alire/indexes
indexes metadata:          OK
index #1:                  (community) git+https://github.com/alire-project/alire-index#stable-1.3.0
toolchain folder:          /home/fernando/.local/share/alire/toolchains
toolchain assistant:       disabled
tool #1 gnat:              gnat_external=13.3.0
tool #2 gprbuild:          not configured
system package manager:    /usr/bin/zypper
distro detection disabled: FALSE

WORKSPACE
root status:               OUTSIDE
root release:              N/A
root load error:           N/A
root folder:               N/A
current folder:            /home/fernando

SYSTEM
distribution:              SUSE
host-arch:                 X86_64
os:                        LINUX
target:                    NATIVE
toolchain:                 USER
word-size:                 BITS_64

Best regards,
Fer

[mosteo]

Will -C retry on the fly, or just resume if a previous file is found? Because if the latter, our temp file cleanup will make -C moot unless some more extensive changes are done too.

[Irvise]

I believe -C works only when rerunning the command... So your observation should hold true and it wont work...

I took another look at the cURL documentation and it seems that the --retry X (with X being a Positive) it will automatically retry the download X times. Maybe using -C and --retry 3 would be a nice combination.

What is your opinion?

[mosteo]

Retrying a couple of times might be OK as long as it doesn't cloud real network issues, I'll have to experiment a bit.

As for -C it looks like it will have to wait for when (if) we implement a centralized cache of partial downloads were it could be resumed from.

I can see how a flaky connection could be a pain for large downloads, so it certainly would be nice to have some improvement in this area.