4 ms·

This is awesome! Is there uv support?[0] One of my biggest gripes about brew is how they manage dependencies. The devs have a conflicting philosophy that crea

This is awesome! Is there uv support?[0] One of my biggest gripes about brew is how they manage dependencies. The devs have a conflicting philosophy that creates bloat. Package maintainers must define settings, settings should always use the latest Python version. It makes no sense. Maintainers won't update unless things break so you got a bunch of Python versions running around. And it won't use system Python! Uv seems to provide an elegant solution for this. You can build a venv for each package and rust version will only have the specified deps. Since uv finds all your Python instances (and packages) and soft links them you have way less bloat and venvs become really useful. You can also use run and other tools to handle executables Plus is also rust so good synergy ;) [0] https://astral.sh/blog/uv https://astral.sh/blog/uv

Kwpolska 2y ago
You should only be using Homebrew for installing software that happens to be written in Python, not dependencies for your own Python projects. If you do that, the Python version does not matter, it's just whatever version is required to make the package work.
- godelski 2y ago
  > not dependencies for your own Python projects I'm not doing that. Honestly I'm not sure how to do that and it sounds like a real pain. > the Python version does not matter This is incorrect. Go check what versions of Python brew has installed for you. It's definitely not your system version... It's not "what works" it is "what the maintainer specified". And according to the brew devs this is supposed to be /the latest version that works/. Which was my point. People don't update just on a Python change. That's not going to happen without automation. (I even suggested we be allowed to specify the minimum version and I was told it's maintainer's responsibilities). You can trivially find packages that can be used with newer versions of Python than their brew formulas specify.
  - pm215 2y ago
    My experience was actually the opposite -- a package I used broke because somebody did an automated "bump the python version this package uses" change without noticing that upstream for the package hadn't yet made a release with the necessary changes to make it work with that python version, so it fell over on startup. (They were quick with reverting it when I reported the problem.)
    - godelski 2y ago
      That happens too. But that's normal bugs. For the issue I'm talking about you have to look. It's a non breaking bug. So unless you look you likely won't see the problem. That's two types of bugs: 1) Those that scream at you 2) Those that hide. We're talking about by later
  - woodruffw 2y ago
    I don't follow the argument here: * One of the main reasons Homebrew doesn't use the "system" Python is because Apple has repeatedly indicated that they want to remove it, and that integrators should not depend on it. This, plus per-package Python version requirements makes using a single system Python a non-starter. * The "bloat" you're noting in Homebrew around multiple Python interpreters is present in `uv` and `pyenv` as well: `uv` handles multiple interpreters transparently, so you may not even realize how many you have installed. I think this is a good pattern: disk space is cheap relative to the timesink of connecting the right Python version to the right set of packages, which is why every distribution scheme (including both Homebrew and Debian) prefers to distribute multiple Python versions.
    - godelski 2y ago
      > because Apple has repeatedly indicated that they want to remove it That's not a reason to not use it. There's absolutely zero reason for me to have two copies of an exact same Python version (e.g 3.11.4). There is rarely reason to have a differing subversions (3.11.3 vs 3.11.4). > is present in `uv` Are you guessing or do you know? Try it out. Prove me wrong. I said they search for versions on your system and link if found. Seriously, look into it > disk space is cheap That's not correct. It's a thing you need to consider when you have to compromise but not an infinite resource. But there's something cheaper than storage: infrequently scanning the system! The problem is when everyone thinks this way then space is no longer cheap (especially with Apple!) Tragedy of the commons In fact it's a big reason I live in the terminal. Because even on a modern M2 air that bloat creeps in. My system is fast and snappy. I have plenty of storage. But this isn't true if I didn't. The creep still happens in these programs but their nature lessens the blows and the likelihood that people care about these things increases.
saint_yossarian 2y ago
https://mise.jdx.dev/ https://mise.jdx.dev/ supports uv through its pipx backend, and is a very good package/tool manager in general.
- godelski 2y ago
  Thanks! I'll check it out!
alexykn 2y ago
love uv <3 I will look into integrating that. Have not decided if and how to implement my own packaging / source build dsl though and will probably open a git poll for that the coming days
- godelski 2y ago
  Awesome! I look forward to see how this progresses! It'll be nice to have a package manager that supports true multithreading and is just overall a lot faster. There's a lot of things that are needed that brew simply just can't do. I haven't played around with this yet (will this weekend!) but I know brew is way too verbose and IO is a big slowdown. Probably doesn't matter because it is written in ruby. But it's an easy thing to miss and is quite common for people to not recognize this. Like when people use `tar xvf` instead of `tar xf`, there's a very noticeable speed difference for many packages lol. (Sorry if I'm preaching to the choir here. It's a pet peeve of mine given how common this is)

Kwpolska 2y ago

You should only be using Homebrew for installing software that happens to be written in Python, not dependencies for your own Python projects. If you do that, the Python version does not matter, it's just whatever version is required to make the package work.

godelski 2y ago
> not dependencies for your own Python projects I'm not doing that. Honestly I'm not sure how to do that and it sounds like a real pain. > the Python version does not matter This is incorrect. Go check what versions of Python brew has installed for you. It's definitely not your system version... It's not "what works" it is "what the maintainer specified". And according to the brew devs this is supposed to be /the latest version that works/. Which was my point. People don't update just on a Python change. That's not going to happen without automation. (I even suggested we be allowed to specify the minimum version and I was told it's maintainer's responsibilities). You can trivially find packages that can be used with newer versions of Python than their brew formulas specify.
- pm215 2y ago
  My experience was actually the opposite -- a package I used broke because somebody did an automated "bump the python version this package uses" change without noticing that upstream for the package hadn't yet made a release with the necessary changes to make it work with that python version, so it fell over on startup. (They were quick with reverting it when I reported the problem.)
  - godelski 2y ago
    That happens too. But that's normal bugs. For the issue I'm talking about you have to look. It's a non breaking bug. So unless you look you likely won't see the problem. That's two types of bugs: 1) Those that scream at you 2) Those that hide. We're talking about by later
- woodruffw 2y ago
  I don't follow the argument here: * One of the main reasons Homebrew doesn't use the "system" Python is because Apple has repeatedly indicated that they want to remove it, and that integrators should not depend on it. This, plus per-package Python version requirements makes using a single system Python a non-starter. * The "bloat" you're noting in Homebrew around multiple Python interpreters is present in `uv` and `pyenv` as well: `uv` handles multiple interpreters transparently, so you may not even realize how many you have installed. I think this is a good pattern: disk space is cheap relative to the timesink of connecting the right Python version to the right set of packages, which is why every distribution scheme (including both Homebrew and Debian) prefers to distribute multiple Python versions.
  - godelski 2y ago
    > because Apple has repeatedly indicated that they want to remove it That's not a reason to not use it. There's absolutely zero reason for me to have two copies of an exact same Python version (e.g 3.11.4). There is rarely reason to have a differing subversions (3.11.3 vs 3.11.4). > is present in `uv` Are you guessing or do you know? Try it out. Prove me wrong. I said they search for versions on your system and link if found. Seriously, look into it > disk space is cheap That's not correct. It's a thing you need to consider when you have to compromise but not an infinite resource. But there's something cheaper than storage: infrequently scanning the system! The problem is when everyone thinks this way then space is no longer cheap (especially with Apple!) Tragedy of the commons In fact it's a big reason I live in the terminal. Because even on a modern M2 air that bloat creeps in. My system is fast and snappy. I have plenty of storage. But this isn't true if I didn't. The creep still happens in these programs but their nature lessens the blows and the likelihood that people care about these things increases.

saint_yossarian 2y ago

https://mise.jdx.dev/ https://mise.jdx.dev/ supports uv through its pipx backend, and is a very good package/tool manager in general.

godelski 2y ago
Thanks! I'll check it out!

alexykn 2y ago

love uv <3 I will look into integrating that. Have not decided if and how to implement my own packaging / source build dsl though and will probably open a git poll for that the coming days

godelski 2y ago
Awesome! I look forward to see how this progresses! It'll be nice to have a package manager that supports true multithreading and is just overall a lot faster. There's a lot of things that are needed that brew simply just can't do. I haven't played around with this yet (will this weekend!) but I know brew is way too verbose and IO is a big slowdown. Probably doesn't matter because it is written in ruby. But it's an easy thing to miss and is quite common for people to not recognize this. Like when people use `tar xvf` instead of `tar xf`, there's a very noticeable speed difference for many packages lol. (Sorry if I'm preaching to the choir here. It's a pet peeve of mine given how common this is)