Me: `brew install black`
Brew: "Ok, upgrading to python 3.11 and reinstalling everything"
@yuvipanda I still don't know why Python _packages_ are on homebrew, as opposed to `brew install python && pip install black` (or pipx!).
@minrk @yuvipanda For stuff like black, it's kind of an implementation detail that it's written in Python, so I think it makes sense to install it via a package manager.
The thornier cases are things like virtualenv.
@yuvipanda @minrk To be fair, `pipx` solves that problem (its how I have `black` installed, I believe), but I think there's a distinction between "apps that happen to be written in Python" and "apps / libraries that need to be in your Python environment".
You could re-write `black` in Rust or C or C++ or something (without Python bindings) and it wouldn't matter, because it's a command line application.
Stuff like `mypy`, `pytype` and `virtualenv` are a grey area because they have Python version-specific features, but they are invoked from the command line, so you *could* rewrite them, but your users are expecting behavior like "`mypy` should be able to see all the libraries installed in the current environment" and "`mypy` uses the Python version of the current environment".
@yuvipanda @pganssle Fair point! I also install it system wide, I just do it with pip (and end up using it most often via pre-commit in a thousand envs anyway).
@pganssle @yuvipanda @minrk And then you have things like pytest that people think should be agnostic and in fact provide an API and thus should be installed into your environment.
We run into this exact issue on VS Code when trying to manage how people have various tools installed when integrating with them (for Black we ship a copy for convenience).
@brettcannon @pganssle @minrk ah ouch, pytest clearly should be installed in same environment as the code it is testing... Shipping a copy of black seems nice
@pganssle @minrk yeah, black is the only tool like this that I try to install cross-env for exactly this reason.