Webi v2

[coolaj86]

Webi's been around for a while now. I think most of the relevant use cases and faults have been encountered.

I think the API and usage should stay about the same, but I'm considering what a v2 would look like and would like to open the floor for feedback and discussion.

In particular, I'm thinking

• the bash should be cleaned up, perhaps more of the content being auto-generated as whole files that are committed to the repo
• backwards compatibility with the initial versions should be removed
• API (both web and expectations for file locations, etc) should be specified
• more explicit output about behavior (especially load.sh and PATH.env)

Feedback

• Automatic PATH updating 🧙‍♂️
  • I'm non-negotiable on having things Just Work™ for the most ignorant of users
  • which means PATH updates happen automatically by default
  • but I 100% agree that changes should be 100% clear to the user
  • and I'm open to having a --no-path-updates option for power users

  curl -L https://webinstall.dev/foobar | bash -s -- --no-path-updates

  • (I made this "for dummies", that it has attracted power users is a pure accident, but I want it to be power-user friendly)
• Automatic deploys 🚀
  • Currently in place. main and hotfix deploy to production on push.
    (there was a hiccup with this a while back, but I think it was simply a matter of accidentally committing to hotfix)
  • All other branches deploy to beta on push
  • I'm interested in running any future auto-generations every 15 minutes or so
• Pre-generated Build Scripts 🤔
  • Some things just can't be done reasonably well in bash
  • so I don't think that this could get to the point of being hosted on GitHub Pages
    (plus I don't like or trust GitHub, generally, but you gotta have it for SEO and stars...)
  • but I'm 100% interested in investigating how far we can go
    (but not to the point of giving up the ability to track # of downloads)
• Mirroring Releases 💵
  • I only use the official 1st releases (with explicitly noted exceptions, which are rare)
  • I don't do mirroring or proxying (this keeps costs near zero, everything comes from GitHub Releases, or official release APIs)
  • If you don't trust the original author, don't use their stuff
  • I'm willing to consider a paid Pro option with releases, but otherwise I don't want the bandwidth costs
• Code Quality 💯
  • All scripts should be updated to pass shellcheck and PSScriptAnalyzer
  • Download tests running nightly 🙋‍♂️ HELP WANTED

Also, I had no idea discussions were enabled on this repo, so sorry for the ones I've missed so far. 🤷‍♂️

[adamcstephens]

Here would be my suggestions/feedback/concerns:

• The use of webinstall.dev to serve all content is a single point of failure and potentially unsafe. Software delivery requires a trusted delivery chain, and as currently designed there is no way to validate what webinstall.dev returns. Since webinstall seems to currently use the releases.js to dynamically serve content, an alternative would have to be found. That alternative could possibly be writing release information into a static file, either manually through PRs (e.g. the homebrew model) or dynamically through CI/CD.
• User config files should not be modified unless absolutely necessary, and if doing so the user should be notified. Personally I would prefer the installer to notify the user of the manual steps to be done to update their shell configuration. (This is what homebrew does for example)

[ajeetdsouza]

• I think we should auto-generate complete installers. They should be able to figure out the target triple of the local machine, check GitHub releases for a matching binary, download and install it on their own. Thus, there would only be one installer generated for each package. This installer can be generated using GitHub Actions and hosted on GitHub Pages. webinstall.dev would simply be a custom domain for this.
  Prior art:
  • https://github.com/goreleaser/godownloader#other-resources-and-inspiration
  • https://sh.rustup.rs/
• +1, I would much rather not have scripts mess with my config files, and I imagine there's a large number of users that would agree. The installer should give out instructions if the required directory is missing from $PATH.

[ajeetdsouza]

One thing I would love to see in Webi v2 is more robustness. Since I have made webi the "recommended" way to install zoxide, I've had users complain to me that installation was broken multiple times. Here's how I suggest we approach this:

• On every commit, run shellcheck on all generated bash scripts.
• On every commit, run PSScriptAnalyzer on all generated PowerShell scripts.
• Every night, run all the scripts to verify that download still works.
• Production should not be deployed manually -- changes to main should automatically update webinstall.dev via GitHub Actions.

Related: https://github.com/webinstall/webi-installers/issues/312

[ajeetdsouza]

Another point I have:

Users who typically check install scripts before executing them are often confused by the fact that the script they downloaded is going to download yet another script, binaries, etc. which makes them trust the installer less. I think installers should in general be self-contained.