Extract Portable Ruby download information into a templatable file

[Bo98]

Verification

• [X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

We currently have complex logic in vendor-install to install Portable Ruby: https://github.com/Homebrew/brew/blob/15dc76c5a7a8e51eb465615206666bf7840d0d61/Library/Homebrew/cmd/vendor-install.sh#L15-L66

This is difficult to machine-update. Ideally this should be extracted so that:

• Version information is read from Library/Homebrew/vendor/portable-ruby-version
• SHA256 information is read from another file

An example system could be a directory (say Library/Homebrew/utils/portable-ruby-sha256/ or similar) that has files x86_64-linux, arm64-darwin and x86_64-darwin with contents something like:

ruby_TAG=el_capitan
ruby_SHA=5c86a23e0e3caee1a4cfd958ed7d50a38e752ebaf2e7c5717e5c8eabaa6e9f12

that we then source appropriately in cmd/vendor-install.sh.

What is the motivation for the feature?

To automate Portable Ruby releases further so that PRs like https://github.com/Homebrew/brew/pull/17399 could be fully automated (larger 3.3 -> 3.4 updates is out-of-scope for now).

How will the feature be relevant to at least 90% of Homebrew users?

Portable Ruby releases reach users a little faster

What alternatives to the feature have been considered?

Continue updating manually

[MikeMcQuaid]

Great idea, thanks @Bo98!

[reitermarkus]

Definitely makes sense to automate this.

What's the difference between updating content in a vendor-install.sh file vs. updating it in a separate file? Obviously a separate file is easier to implement, so I guess my actual question is where does the update come from? The homebrew-portable-ruby release workflow? A workflow in this repo? Dependabot?

[Bo98]

The homebrew-portable-ruby release workflow?

Probably this.

What's the difference between updating content in a vendor-install.sh file vs. updating it in a separate file?

Sed replacing ruby_SHA based on pattern matching of the previous line is a bit messy but not impossible. It gets even more complicated when the minimum macOS changes (i.e. we change el_capitan to sierra) as we need to then parse the previous tag information too.

With a separate file you don't need all that at all as you can just do

echo > x86_64-darwin <<<EOS
ruby_TAG=${TAG}
ruby_SHA=${SHA}
EOS

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[alebcay]

https://github.com/Homebrew/brew/pull/17557 landed in https://github.com/Homebrew/brew/releases/tag/4.3.8.