darkamaul
5 months ago
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
5 months ago
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
5 months ago
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
5 months ago
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
5 months ago
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.