Scripts VS homebrew-core

I have 3, listed here: https://github.com/captn3m0/scripts

* split-audio-by-chapters (Based on metadata inside the AAX file)

* split-by-audible (If audible doesn't provide splits in the m4a, but chapters are marked in the web/mobile player - you can copy the chapter listing and use this). See source for format.

* split-by-silence (In some cases audible doesn't provide any chapters at all, and this is my last-ditch effort).

I learned while working on a new Kubernetes course that the official way of installing the AWS CLI on macOS per their documentation [^0] installs the x86 version of the CLI and that Apple Silicon is, mysteriously, not supported.

The Homebrew formula works around this by building from source [^1], but not everyone uses Homebrew, including me, for this course.

This script I wrote remediates this. It's a quick and easy way of installing the AWS CLI without a package manager or having to dig through GitHub Gists or Homebrew formulas yourself.

I hope someone out there finds this useful!

[^0]: https://docs.aws.amazon.com/cli/latest/userguide/getting-sta...

[^1]: https://github.com/Homebrew/homebrew-core/blob/master/Formul.... Notice how the awscli dependencies are downloaded as separate packages. This might not be what you want.

If you use Homebrew it’s not available there yet, but it’s being added. See https://github.com/Homebrew/homebrew-core/pull/209124.

Yes, I am aware of all of those, although I couldn't offhand tell anyone the difference in tradeoffs between them. But I consider having to install a fresh copy of the whole distribution a grave antipattern. I'm aware that nvm and pyenv default to it and I don't like that

I did notice how Homebrew sets env GEM_HOME=/libexec GEM_PATH=/libexec (e.g. <https://github.com/Homebrew/homebrew-core/blob/9f056db169d5f...>) but, similar to my node experience, since I am a ruby outsider I don't totally grok what isolation that provides

I'm in the camp of "if I can't build it, then it's not open source" so https://github.com/Homebrew/homebrew-core/blob/d314f3ebba9e7... is a good start, but there is no .../f/flutter.rb although there is https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=flutt... but I haven't been soaking in the AUR ecosystem long enough to be able to port it to Homebrew

All those words to say that if there was a .github/workflow/release.yml showing the steps required to cook a release artifact that would be the best(?) documentation since it is kind of like a Dockerfile in that it's computer executable but mostly human readable

$ brew info eza ==> eza: stable 0.18.13 (bottled) Modern, maintained replacement for ls https://github.com/eza-community/eza Not installed From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/e/eza.rb License: MIT ==> Dependencies Build: pandoc ✘, pkg-config ✔, rust ✘ Required: libgit2 ✘ ==> Analytics install: 12,792 (30 days), 38,295 (90 days), 68,375 (365 days) install-on-request: 12,790 (30 days), 38,293 (90 days), 68,375 (365 days) build-error: 0 (30 days)

Is disabling the compromised repo the typical GitHub policy? My concern is there are monorepos used by package managers, like brew, that are a collection of thousands of projects [1]. These monorepos seem like a prime target for attack and if GitHub disables one because a malicious commit was merged then you've taken down an entire ecosystem.

[1] https://github.com/Homebrew/homebrew-core

> Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution.

[1] https://github.com/Homebrew/homebrew-core/pull/167512

> right, but now you know even less about your setup when you some roadblock

This is the same with a binary though. And with homebrew, you can't follow patches or flags used or if they change.

- https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad...