Replace wget on Windows with built-in curl

[paulober]

Since Build 17063 (Win 10) Windows includes a curl distribution. This PR replaces the usage of wget with the built-in curl executable.

See https://curl.se/windows/microsoft.html for reference.

@tdewey-rpi @will-v-pi

[stephanosio]

One of the reasons why wget was chosen over curl initially was that it has a much nicer progress bar showing file name, download size, download speed and remaining time, whereas curl has a very basic and ugly progress bar that provides none of the aforementioned details.

Given that we recommend and depend on wget for many other things in the documentation and wget can be easily installed using winget alongside many other components that are not available on Windows, I am not convinced that this is a necessary change.

[paulober]

One of the reasons why wget was chosen over curl initially was that it has a much nicer progress bar showing file name, download size, download speed and remaining time, whereas curl has a very basic and ugly progress bar that provides none of the aforementioned details.

Given that we recommend and depend on wget for many other things in the documentation and wget can be easily installed using winget alongside many other components that are not available on Windows, I am not convinced that this is a necessary change.

Understood. The thing is if you want to integrate zephyr setup into your tooling you have other more convenient options to download the rest so then wget would only be required to run this script which is really not necessary. So what about keeping wget the default and give an option via flag / fallback to use curl?

[paulober]

If you accept this solution I would also like to add it as option / fallback to macOS as it has also curl installed by default and wget would need to be installed separately.

[stephanosio]

Understood. The thing is if you want to integrate zephyr setup into your tooling you have other more convenient options to download the rest so then wget would only be required to run this script which is really not necessary. So what about keeping wget the default and give an option via flag / fallback to use curl?

7z, another utility not available by default on Windows, will need to be installed or provided in some way for this script to run; so, I do not really understand the desire to use curl on the basis that it is already available on Windows -- the script will not be able to run on vanilla Windows anyway.

The question is: why is it so hard to provide wget as with 7z, which you will need to provide anyway, in your tooling?

[paulober]

7z, another utility not available by default on Windows, will need to be installed or provided in some way for this script to run; so, I do not really understand the desire to use curl on the basis that it is already available on Windows -- the script will not be able to run on vanilla Windows anyway.

The question is: why is it so hard to provide wget as with 7z, which you will need to provide anyway, in your tooling?

Thanks for the clarification! I completely agree that 7z is unavoidable — it’s a required tool, so adding that dependency makes sense.

What I’m trying to highlight is that wget doesn’t really fall into the same category. Adding it introduces:

• Extra complexity: one more binary to download, host, and maintain. (mostly maintain the download links and check that the third party keeps the wget binary updated with the latest security patches by the wget team)
• Fragile indirection: depending on a third-party binary hosted in a third-party repo, downloaded through another third-party package manager (e.g. winget) that might not even be installed on the users computer (we often had that issue).
• Little to no benefit (in our scenario): the main difference is a progress bar, but in non-interactive/headless setups (which are fairly standard these days: ci, IDEs, toolchain installers, fleet management with remote installs) that’s not visible anyway.

In contrast, both macOS and Windows already ship with curl by default. Relying on built-in system utilities reduces external dependencies, improves reliability, and avoids unnecessary setup friction.

So my suggestion isn’t to drop wget (I think your point is perfect valid and for people who follow the guide and do it manually can benefit of these advantages), but to add curl as a fallback (and opt-in flag). That way, users benefit from system-provided tooling where available, and we don’t increase maintenance overhead or complexity.

[stephanosio]

It does actually increase the maintenance overhead for us ensuring the identical behaviour across two different tools and dealing with the potential bug reports related to this.

wget is referenced throughout the Zephyr documentation, including the Getting Started Guide, and installing/providing it should be almost effortless.

Also note that you will need a lot more than just wget to be able to set up Zephyr build environment; so, my suggestion is to just provide wget alongside many other tools you will need to provide anyway.