Proposal: brew type

[woodruffw]

First of all, thank you for creating and maintaining this spec! I think it's a great idea, and I'm looking forward to using (and contributing to) it.

I'm opening this to start a rough sketch of a purl type for Homebrew formulae.

Some initial bits:

• The default repository should probably be homebrew/core
  • Homebrew's tap syntax is {org}/homebrew-{tap} for GitHub taps, so homebrew/core corresponds to https://github.com/homebrew/homebrew-core
• The name is the Formula name
  • Formula names can contain @ (e.g. llvm@17), so this will need to be percent-encoded
  • Formulae with name@version are typically "fixed" versions,
• The version is the Formula version
• Qualifiers:
  • revision (when the formula itself is patched) (is this worth including?)
  • version_scheme (when the version ordering is changed, similar to epochs in Python) (is this worth including?)
  • Bottle checksum/tag/rebuild (it may not make sense to include these, since resolving the formula itself resolves them)
  • Other things I'm forgetting?

Things not covered (yet):

• Casks

So, some rough examples:

# equivalent: implicit namespace and explicit
pkg:brew/sqlite@3.43.2
pkg:brew/homebrew/core/sqlite@3.43.2

# third-party tap
pkg:brew/stripe/stripe-cli/stripe@1.18.0

# percent-encoding for AT-formulae (implicit and explicit underlying version)
pkg:brew/openssl%401.1
pkg:brew/openssl%401.1@1.1.1w

CC @p-linnane @colindean @SMillerDev as interested parties 🙂

[colindean]

Something that I'd like to see in this is perhaps query parameters to set the tap URL and name so that private taps even those off of GitHub can use it effectively.

pkg:brew/myteam/mytap/myapp?tap_name=myteam/mytap&tap_url=https://git.example.com/myteam/mytap.git

Homebrew would handle this by tapping that URL with the given name and then installing the myapp formula.

The tap_name could be inferred from the second..N-1 level of the path instead of being specified explicitly.

[SMillerDev]

Thanks for writing this @woodruffw . Some comments and clarifications:

Formulae with name@version are typically "fixed" versions

The version itself is not fixed as much as the range is. python@3.11 can get new 3.11 releases but it'll never get a 3.12 release.

revision (when the formula itself is patched) (is this worth including?)

In general in package managers this is seen as part of the version since it can be a very different package between revisions. Not sure if that applies to purl too.

version_scheme (when the version ordering is changed, similar to epochs in Python) (is this worth including?)

For an identifier this is already part of the version information. If a package switches from calver to semver you'll have a different version.

Bottle checksum/tag/rebuild (it may not make sense to include these, since resolving the formula itself resolves them)

Yeah, agreed. Bottles seem a step too detailed for a first draft.

[woodruffw]

The version itself is not fixed as much as the range is. python@3.11 can get new 3.11 releases but it'll never get a 3.12 release.

Yep, thanks for clarifying this!

[woodruffw]

From here, the next step is probably to get an initial 👍 from the purl folks and then open up an initial PR (I can do this).

[woodruffw]

CC @pombredanne @stevespringett anything else we should do here? Otherwise I'll go ahead and start on a PR 🙂

[stevespringett]

Is the target platform something this purl type should support? I use homebrew on macOS all the time, but I know it also supports Linux. Can formulas differ between platforms and is that logic embedded in a formula?

Is there a need to call out cast as something potentially different? How would a cast be represented in purl?

[SMillerDev]

Can formulas differ between platforms and is that logic embedded in a formula?

Some formulae only work on a single platform, but there is no way to have a macos-node package

[woodruffw]

Is the target platform something this purl type should support? I use homebrew on macOS all the time, but I know it also supports Linux. Can formulas differ between platforms and is that logic embedded in a formula?

Building off what @SMillerDev said: Homebrew formulae themselves are notionally platform independent (although they may only build on some platforms).

I think the closest analogy is PyPI with sdists and wheels: a formula is like an sdist, and brew install may attempt to either install a binary build or perform a source build depending on the host's state. So from a URL/reference perspective, not including any sort of platform tag (by default) probably makes the most sense 🙂

Is there a need to call out cast as something potentially different? How would a cast be represented in purl?

A Cask is more or less a macOS .app. They have their own complexities (they're binary only, they can perform their own version updates, they may or may not have multiple internal platform-specific executables, etc.), so fitting them into the same format as formulae might be a little tricky/lose information. My suggestion would be to try and encode them as a separate type (cask or brewcask or similar?)

[p-linnane]

A Cask is more or less a macOS .app. They have their own complexities (they're binary only, they can perform their own version updates, they may or may not have multiple internal platform-specific executables, etc.), so fitting them into the same format as formulae might be a little tricky/lose information. My suggestion would be to try and encode them as a separate type (cask or brewcask or similar?)

To add to this, while formulae in homebrew-core are all open source with OSI-approved licenses, casks are often closed source software. The cask definition files are essentially a pointer to where to grab upstreams published binaries.

[colindean]

Formulae in private taps are often binary formulae, meaning their source URL doesn't contain source code but a pre-compiled binary. This is common inside the firewall where companies don't have or need Homebrew's build infrastructure. The tap_url parameter would handle this case well.

[woodruffw]

Tracking: Assigning the PR for this to @josephsweeney on our side 🙂

[woodruffw]

We've opened #281 for this!