undefined | Better HN

0 pointsmixmastamyk1y ago0 comments

>> 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.

0 comments

TeMPOraL1y ago

> "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.

mixmastamykOP1y ago

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.

TeMPOraL1y ago

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

1 more reply

orra1y ago

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.

mixmastamykOP1y ago

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

lmm1y ago

> 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.

mixmastamykOP1y ago

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

lmm1y ago

> 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.

1 more reply

j / k navigate · click thread line to collapse

0 pointsmixmastamyk1y ago0 comments

>> 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.

0 comments

TeMPOraL1y ago

> "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.

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.

mixmastamykOP1y ago

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.

TeMPOraL1y ago

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

1 more reply

orra1y ago

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.

mixmastamykOP1y ago

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

lmm1y ago

> 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.

mixmastamykOP1y ago

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

lmm1y ago

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

1 more reply

j / k navigate · click thread line to collapse