Support for uv

[martimlobao]

uv is, among other things, becoming an extremely popular way to run and install Python-based tools like ipython, mypy or sqlfluff. Adding support for uv in Brewfiles would be a nice addition.

[jacobbednarz]

generally, we want to have multiple requests before we add any new ecosystem support for things like this to avoid building things that don't benefit others more broadly.

given it's not the pseudo standard today, i'd also be hesitant in adding support until it gains more usage.

[martimlobao]

generally, we want to have multiple requests before we add any new ecosystem support for things like this to avoid building things that don't benefit others more broadly.

given it's not the pseudo standard today, i'd also be hesitant in adding support until it gains more usage.

That's a very valid concern. I have a couple of questions:

1. I've taken a look at the repo and at least at first glance, it seems relatively straightforward to add support myself (seems like mostly just adding a different version of these files 1 2 3 4 5). Does this seem like a somewhat reasonable task to you or am I potentially overlooking something that might make this much more difficult?
2. If I did do that, would creating a PR for this be worthwhile or is there still a concern that doing so will bring the need to maintain this going forward?

[jacobbednarz]

if we decided this was worth adding, a PR is always welcome.

for me, i don't yet think we have enough of a request backlog for uv being included so i would probably pass based on my knowledge of it today. personally, this gives a higher signal that we need an agnostic plugin system that gets all of these requests out of core bundle and allows folks to hook into ecosystems if they choose to without additional core support for these things.

[martimlobao]

A plugin system for custom support sounds like an awesome idea!

[MikeMcQuaid]

uv is, among other things, becoming an extremely popular way to run and install Python-based tools like ipython, mypy or sqlfluff.

These tools all exist in Homebrew already. Why would you want to install them using uv but still through brew (bundle`)?

I'm not strongly opposed (yet!) but I do think it makes sense to avoid overlapping ecosystems here.

[martimlobao]

uv is, among other things, becoming an extremely popular way to run and install Python-based tools like ipython, mypy or sqlfluff.

These tools all exist in Homebrew already. Why would you want to install them using uv but still through brew (bundle`)?

I'm not strongly opposed (yet!) but I do think it makes sense to avoid overlapping ecosystems here.

This is true, and it was something I considered when deciding whether to install them using using brew or uv. The main reason I chose to go with uv is that it allows you to install virtually any python package, including things that aren't available on Homebrew, such as airflow or marimo. Obviously, for things like ipython which are also available on Homebrew I could have gone with either option, but for consistency's sake I find it easier to install all Python packages using the same tool.

The reason for using bundle is merely for the convenience of a reproducible setup without having to build my own tooling to achieve something that has already been done.

[MikeMcQuaid]

Ok, thanks for explaining I think we'll pass on this for now but: anyone else who wants uv for this: shout and we're more likely to consider.

Would definitely be game to accept a PR to add a plugin system here though, @martimlobao!

[lemeb]

Just chiming in to say that uv is worth considering for addition in the medium-run. I'm not sure installing packages is a good idea, but installing tools (like marimo) is. Tools in uv are meant to be used system-wide: https://docs.astral.sh/uv/guides/tools/ This is why uv is different from pip/pipx.

I agree that uv is still early, and it's fair to wonder if the universe of tools that are available through pip but not through homebrew is large enough to justify inclusion. Still, I think it's worth thinking about.

Thanks :)

[MikeMcQuaid]

installing tools (like marimo) is.

@lemeb out of interest: why would installing this with uv rather than brew be better?

[lemeb]

installing tools (like marimo) is.

@lemeb out of interest: why would installing this with uv rather than brew be better?

I definitely agree with the principle that if a tool can be installed by brew, it should be installed by brew.

Nevertheless:

1. A lot of pip CLI utilities haven't been ported to homebrew yet. I was wondering if I could quantify that, so I looked at the tools being showcased by pipx, which is also meant to install CLI utilities and not libraries. Of the 20 packages listed there, I see at least 5 that don't have a formula (shell-functools, pyxtermjs, hexsticker, pybabel, create-python-package). It's not the end of the world, but there's a long tail of packages that isn't captured by homebrew just yet.

2. You can install a package from git. (I recognize you might view this as actually undesirable!)

3. You can specify versions of the tools. (Same remark about this being undesirable.)

That's what I can come up with on top of my head. I'll add another comment if I can think of more. (uv is pretty agressive in terms of downloading pre-built Python binaries to ensure complete isolation, and that might be an advantage, although I'm not sure.)

Thanks! :)

[lemeb]

To put it in another way: technically, probably any package that can be installed by uv tool can be installed by brew. But there are a lot of packages that, for better or for worse, will not yield acceptable formulae, either because the user asks for a specific version, git repo, wants a non-free CLI tool, is interested in a niche package, etc.

[colindean]

I'm tepid on this idea, leaning toward a not yet for uv but not a never.

uv

I'm not sure yet on uv's installation and management of its own Python, and what support burden that might shift to Homebrew. uv is also maturing rapidly but not yet 1.0.0, so things may change. I'd be warmer on the idea when it achieves that stability. @MikeMcQuaid has a far better concept of these risks, however major or minor they may be.

pipx

I think it's in-bounds to add pipx support that would:

1. ensure pipx is installed with brew install pipx, this would install+use Homebrew's managed Python because of PIPX_DEFAULT_PYTHON=/opt/homebrew/opt/python@3.13/libexec/bin/python
2. install a package with ${brew_prefix}/pipx install ${package}

pipx 'ruff'

ideal

I like the idea of having something like this for installing ruff ¹:

# set which to use
use_mgr :python, 'uv'
use_mgr :python, 'pipx'
# invoke with
python "ruff"
# or maybe this, with ':using' having a default of pipx?
python "ruff", using: :uv
python "ruff", using: :pipx

but this may be too abstract for real needs and the lift would be far greater to implement and maintain.

UX

But in the face of this, what's easier for the user?

1. pipx "mypackage"
2. Build a formula using the Python instructions and put the formula in a (new) tap or upstream it?
3. Use my favorite at_exit to take actions after brew bundle runs, including running uv tool install or pipx install.

Footnotes

1. Yes, I know Ruff has a Homebrew formula, it's just the first thing that comes to mind that's installable with pipx and uv in this mode. ↩

[MikeMcQuaid]

but this may be too abstract for real needs and the lift would be far greater to implement and maintain.

Yes, sorry. Let's keep pipx/ruff out of the scope of this issue and focus on uv, please.

[colindean]

I'm also in support of a plugin system. That'd be a neat power to gain because there are some other ecosystems requested that just don't have enough support for us to maintain.