[aria2] use env variable to use aria2 download tool

[cenit]

Describe the pull request

• What does your PR fix?

  Fixes [aria2] use environment variable to select download tool #17934

• Which triplets are supported/not supported? Have you updated the CI baseline?

  <N/A>

• Does your PR follow the maintainer guide?

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

@JackBoosY it seems easier than expected.
I added a VCPKG_DOWNLOAD_TOOL env variable symmetric to the already-in-use _VCPKG_DOWNLOAD_TOOL managed by the cli switch --x-use-aria2

[JackBoosY]

Okay, I will take over this PR.

[cenit]

it might require also cenit/vcpkg-tool@2364e22

I can open a PR also on vcpkg-tool if it's the right way to proceed with this problem

[cenit]

it works locally (together with the PR on the vcpkg-tool microsoft/vcpkg-tool#85), I hope the same is valid for anyone willing to try.

I am sorry for the full rebuild that this PR is triggering, but I hope for this PR to be considered for merging. The full rebuild is totally unnecessary because it's using the "old" vcpkg-tool and in any case would not have the env variable defined even using the newer one

main reason for this PR: I don't know why, but cmake built-in download is really very broken on windows behind proxy, while at the same time aria2 always works flawlessy

[cenit]

@strega-nil @strega-nil-ms please let me know if the modification is not coherent with the idea behind env variables. To pilot vcpkg in manifest mode they are almost the only way that I know

[cenit]

@JackBoosY any news here (and vcpkg-tool related PR)? it might be very useful for people behind corporate firewalls!

[JackBoosY]

Oh sorry, last week I'm working on #18201.
Will handle this PR this week.

[cenit]

merged with master just to be sure that the recent #13639 was not interfering in the logic.
It seems that it's still ok without any required modification @JackBoosY

[ras0219-msft]

We'd really like to see the aria functionality moved into the vcpkg tool and remove the remaining workaround in vcpkg_download_distfile(). That way it will be applied uniformly even for our other downloads that are performed inside vcpkg.exe.

[JackBoosY]

@ras0219-msft Can you describe it in more detail?
I think that even if aria2 is used to download files uniformly, vcpkg_download_dstfile should exist as a wrapper.

[cenit]

We'd really like to see the aria functionality moved into the vcpkg tool and remove the remaining workaround in vcpkg_download_distfile(). That way it will be applied uniformly even for our other downloads that are performed inside vcpkg.exe.

with or without using libaria2? https://github.com/aria2/aria2#libaria2
To be honest, I really like unix philosophy of keeping it simple. So why should vcpkg also become a download tool? I understand that x-download is already in, but why?

[cenit]

also, is this PR even considered for now or would you prefer a full solution immediately with aria/aria-like download integrated into vcpkg?
I understand that this (imho long due) env variable can offer a quick solution, but I understand that I am trying to "quick solve" a problem which I also do not fully understand. If you ask me why aria2 (or browser) succeeds while cmake or vcpkg fail at download the same file on the same node in the same network, well I don't know

[BillyONeal]

This is not correct because you've bypassed the part that acquires aria2 in the first place; I think if you want to do this it really does need to be in the tool proper (and it needs to be validity checked instead of an open ended string like this... the current leading underscore form is OK because we know where it's being set...)

[ras0219]

So why should vcpkg also become a download tool?

The idea is not that vcpkg should implement HTTP, but rather that:

1. vcpkg itself must download things (cmake, ninja, git, binarycaching, etc)
2. portfile.cmake needs to download things (sources, buildsystems)
3. We want to be able to uniformly customize and control downloading (source mirroring, authentication, proxies)

Therefore, it makes sense that vcpkg is the uniform entry point for all downloading; it then internally can dispatch to whatever mechanism is appropriate (WinHTTP, curl, aria2).

I'd prefer to avoid this half-solution, since we know we need to move all download functionality into the tool very soon.

[cenit]

ok, understood. Closing the PR, and looking forward to seeing the new unified architecture :)