search

package-url / purl-spec

A minimal specification for purl aka. a package "mostly universal" URL, join the discussion at https://gitter.im/package-url/Lobby
https://github.com/package-url/purl-spec
Other
699 stars 161 forks source link

Proposal: `brew` type #254

Open woodruffw opened 1 year ago

woodruffw commented 1 year ago

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:

Things not covered (yet):

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

stevespringett commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

woodruffw commented 11 months ago

We've opened #281 for this!