doc: add Webi as install method

[coolaj86]

Preview changes at

https://github.com/coolaj86/xcaddy/tree/patch-2#install

[emilylange]

I am heavily against this.

I believe this suggests that this is some sort of officially supported installation method -- which it isn't.
Furthermore, it pipes curl into sh/bash, which is a really really bad idea -- no explanation needed.

And I would have appreciated it, if you would have explicitly disclosed your involvement into that project, but oh well.

[coolaj86]

@emilylange Webi is already an official install method for Caddy itself and although you say "no explanation needed"... can you come up with 1 reason why shell pipes are "bad"?

(the reasons date back to authoritative, out-of-band checksums of files distributed on floppy disk, and early issues with encryption-and-checksum-in-transit in the pre ssl-era)

https://webinstall.dev/faq/#dont-run-with-shell-pipes

Brew, Rust, Ruby, and many others all operate installers with shell pipes or the equivalent (npm, apt, etc). GoReleaser creates install shell files too. In the modern era of HTTPS there's no technical limitation that makes shell piping a bad idea.

[francislavoie]

No webi is not "official", it's under the "community maintained" section. https://caddyserver.com/docs/install

[coolaj86]

Sure. Same as brew and the others.

To be clear, I'm all for this using GoReleaser install scripts as well. Just something that downloads the latest release, sets the exec bit, puts it in the PATH, and done.

[mholt]

I'm not against Webi in principle. But since you already need Go installed to use xcaddy, I don't see a reason for another installation method on top of the 3 we already have?

[coolaj86]

Now that, is a good point! :)

In fact, we recently had this discussion about a tool that depends on Rust and a tool that depends on Node, which lead to this as the litmus test:

Who is the primary audience? Is it limited strictly to developers of the toolchain, or is it a wider audience for whom the toolchain is in the way?

In the case of xcaddy, it passes because the primary audience of xcaddy is NOT Go developers - it's people who would rather not have to deal with Go at all.

(and certainly don't want to have to remember it's conventions for downloads, etc)

The primary audience of xcaddy is people who want to use Caddy with DNS Providers for wildcard certs and domains on private networks and really only use xcaddy because the auto build site was down for about a year. (might be back up now?)

That all said, the primary benefit is convenience and speed. webi xcaddy makes xcaddy available and ready to use in a matter of seconds, regardless of the previous state of the machine (had Go, didn't have Go, had PATH set, didn't have PATH set, etc).

[mholt]

At this point... I think webi is good overall, and like I said I'm not really opposed to this, I'm neutral -- but we do have a team member who is still opposed, and I respect that. I'd be OK merging this if we can find a compromise, like maybe addressing their concerns so that it's clear it's not an official install method but is community contributed (which is not bad IMO).

[emilylange]

@coolaj86 could you try adding webi to repology.org?

No idea how difficult that would be.

But this would allow us to simply embed the repology vertical badge from https://repology.org/project/xcaddy/badges instead of having to file PRs for every single package repository/manager :)

What do you think?