curl curl curl

[eirikb]

Hi @koppor . I've been thinking - what about using curl as much as possible?

Initially I figured I had two options/paths:

1. Use only stage3 (the OS-arch C-binary) to keep everything consistent
2. Use stage3 only when necessary (outdated OSes)

Now I have already abandoned stage3 for Windows, in favor of PowerShell because I had a lot of issues with the C binary there.
So perhaps I should just follow path 2?
This means dropping stage3 for macOS as well, since there curl is bound to be set (until they invent containers for mac, but I doubt that will happen).

Meaning:
Using curl when possible - if it fails use stage3 if present - if that fails then fail.

• Windows: Uses only PowerShell, no stage3
• macOS: Uses only curl, no stage3
• Linux: Uses curl if present, and if curl fails (e.g., outdated certs) then fall back to stage3

Worth noting that a lot of linux containers might have outdated certs, and the big ones, such as ubuntu and debian doesn't have curl or certificates at all, meaning there stage3 will always be used.
alpine container image has a silly version wget I'd rather not support, so stage3 would be used there as well.

In the end:

• Good: Mostly HTTPS and not HTTP (as it is now on linux/macOS)
• Good: Smaller gg.cmd (drops 2 stage3 builds)
• Bad: Might be harder to control how the download progress is displayed
• Bad: Adds complexity on handling curl as CLI and hoping it doesn't change
• Bad: Adds complexity on handling fallback both on missing curl and curl error
• Bad: Several different ways to download stage4 - but this is already a bit complex now because of Windows PowerShell

[koppor]

I read: If this is done, only c binaries for Linux have to be build; not for macOS any more. This sounds good. Maybe, always use custom-binary for linux? Why bother with different curl versions if the probability of curl being non-installed is high?

[eirikb]

I'm not sure how high probability of non-installed is in general. For containers it is probably high, for desktops probably low.
I think the code for mac support will be identical to linux - I hope the CLI interface is identical enough for simple usage by gg.cmd - even with some progressbar.
Meaning they share same curl code, only difference is c binary fallback only on linux.

[koppor]

https://www.reddit.com/r/Ubuntu/comments/eymwrv/what_is_the_reason_why_curl_isnt_installed_on/ :)

[eirikb]

Aha. I don't think I would like to support both wget and curl - or any bastard wget like on alpine.
Perhaps leaving it as-is for linux would be best for now.

[koppor]

I would like to keep these bars if possible :) - I think, we are talking about bootstraping, thus these bars are untouched ^^

[eirikb]

Those bars are part of the rust binary so that would be the same. curl would only be used to download that (stage4)

[eirikb]

Doing some housekeeping in old discussions.

I never went this way. stage3 is still there doing the downloading, and there is no curl in stage1 or stage2. Actually adding more to stage3 right now (sha256), so if anything it went the opposite direction.
I might go back on this later, easy to change, but for now this is how it is.

@koppor your bars are safe.

Closing this one.