Really informative read, I agree that Homebrew’s naming conventions can be frustrating at times, but overall it’s such a great tool.

I hadn’t realized it was this simple to spin up your own tap for distributing tools. How does this compare to using language specific tools (like uv, for example)? Is it better because that’s easier for folks not within the ecosystem ?

▲ searls 3 days ago | parent | next [-]

Thanks!

To answer your question, other tools with package registries typically require accounts, increasingly 2FA, often encourage some sort of signing step. Having GitHub's ToS serve as the source of trust really simplifies things for the Homebrew team

▲ thewisenerd 3 days ago | parent | prev [-]

specifically for python packages,

while it's lightweight, shipping the kitchen sink (uv) is a no-go

so, it's a venv, with the pinned dependencies installed [0], a random example of how this looks like, here [1]

(specifically for uv; i tried to get `brew update-python-resources` and `homebrew-pypi-poet` working for a "private" package, it didn't really work; so i went ahead and created uvbrew [2] instead to help with the resource generation)

[0]: https://docs.brew.sh/Python-for-Formula-Authors [1]: https://github.com/hynek/homebrew-tap/blob/main/Formula/doc2... [2]: https://github.com/thewisenerd/uvbrew

▲ thewisenerd 3 days ago | parent [-]

that said, it's _really_ easy to have executables against random sdist with `uv run --with`.

here's something that i was writing just yesterday:

    #!/usr/bin/env bash
    PYSTABLE="3.13"
    SERVER="..."
    PACKAGE="xyz"
    VERSION="0.1.3"
    exec uv run --python "$PYSTABLE" --with "$SERVER/$PKG-$VERSION.tar.gz" "$PKG" "$@"

	▲	andrewaylett 3 days ago \| parent [-]
		Now stick the wrapper in a git repo, get Renovate to bump the version numbers, automagic release on new version, and have Brew install the wrapper.