[mixmastamyk]

>> You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment.

>True, but it's not best practice to do that because while the tool gets installed globally, it is not necessarily linked to a specific python version, and so it's extremely brittle.

"Globally" means installed with sudo. These are installed into the user folder under ~/.local/ and called a user install by pip.

I wouldn't call it "extremely brittle" either. It works fine until you upgrade to a new version of python, in which case you install the package again. Happens once a year perhaps.

The good part of this is that unused cruft will get left behind and then you can delete old folders in ~/.local/lib/python3.? etc. I've been doing this over a decade without issue.

[TeMPOraL]

> "Globally" means installed with sudo. These are installed into the user folder under ~/.local/ and called a user install by pip.

> It works fine until you upgrade to a new version of python, in which case you install the package again.

Debian/Ubuntu doesn't want you to do either, and tell you you'll break your system if you force it (the override flag is literally named "--break-system-packages"). Hell, if you're doing it with `sudo`, they're probably right - messing with the default Python installation (such as trying to upgrade it) is the quickest way to brick your Debian/Ubuntu box.

Incredibly annoying when your large project happens to use pip to install both libraries for the Python part, and tools like CMake and Conan, meaning you can't just put it all in a venv.

[mixmastamyk]

Not Debian specific. The braindead option was added by pip to scare off newbies.

No one with the most basic of sysad skills is “bricked” by having to uninstall a library. Again have not experienced a conflict in over 15 years.

Use the system package manager or buid yourself for tools like cmake.

[TeMPOraL]

Uninstalling a library - no. But I specifically mentioned trying to upgrade system Python, which is a quick way to break e.g. apt.

[mixmastamyk]

Ok, getting it now. I said upgrade python, and you thought I meant upgrade the system python in conflict with the distro. But that's not really what I meant. To clarify... I almost never touch the system python, but I upgrade the distro often. Almost every Ubuntu/Mint has a new system Python version these days.

So upgrade to new distro release, it has a new Python. Then pip install --user your user tools, twine, httpie, ruff, etc. Takes a few moments, perhaps once a year.

I do the same on Fedora, which I've been using more lately.

[orra]

Nah, pip is still brittle here because it uses one package resolution context to install all your global tools. So if there is a dependency clash you are out of luck.

So that's why pipx was required, or now, UV.

[mixmastamyk]

Not happened in the last fifteen years, never used pipx. See my other replies.

[lmm]

> It works fine until you upgrade to a new version of python, in which case you install the package again.

Or you install a second global tool that depends on an incompatible version of a library.

[mixmastamyk]

Never happened, and exceedingly unlikely to because your user-wide tools should be few.

[lmm]

> exceedingly unlikely to because your user-wide tools should be few.

Why "should"? I think it's the other way around - Python culture has shied away from user-wide tools because it's known that they cause problems if you have more than a handful of them, and so e.g. Python profilers remain very underdeveloped.

[mixmastamyk]

There are simply few, I don't shy away from them. Other than tools replaced by ruff, httpie, twine, ptpython, yt-dlp, and my own tools I don't need anything else. Most "user" tools are provided by the system package manager.

All the other project-specific things go in venvs where they belong.

This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error.

If a libraries conflict, uninstall them, and put them in a venv. Why do all the work up front? I haven't had to do that in so long I forget how long it was. Early this century.

[lmm]

> This is all a non-issue despite constant "end of the world" folks who never learned sysadmin and are terrified of an error.

It's not a non-issue. Yes it's not a showstopper, but it's a niggling drag on productivity. As someone who's used to the JVM but currently having to work in Python, everything to do with package management is just harder and more awkward than it needs to be (and every so often you just get stuck and have to rebuild a venv or what have you) and the quality of tooling is significantly worse as a result. And uv looks like the first of the zillions of Python package management tools to actually do the obvious correct thing and not just keep shooting yourself in the foot.

[mixmastamyk]

It’s not a drag if you ignore it and it doesn’t happen even once a decade.

Still I’m looking forward to uv because I’ve lost faith in pypa. They break things on purpose and then say they have no resources to fix it. Well they had the resources to break it.

But this doesn’t have much to do with installing tools into ~/.local.