Comment by zahlman | Hacker News Reader

Comment by zahlman | Hacker News Reader

Parent Full thread

> the essential system Python should be in /usr/sbin

There's still quite a bit you can do with the "system Python". Mine includes NumPy, bindings for GTK, QT5 and QT6, Freetype, PIL....

> insofar Python allows that with its __pycache__ spam

This is, to my understanding, precisely why the standard library is pre-compiled during installation (when the process already has sudo rights, and can therefore create the `__pycache__` folders in those locations). This leverages the standard library `compileall` module — from the Makefile:

   @ # Build PYC files for the 3 optimization levels (0, 1, 2)
   -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
    $(PYTHON_FOR_BUILD) -Wi $(DESTDIR)$(LIBDEST)/compileall.py \
    -o 0 -o 1 -o 2 $(COMPILEALL_OPTS) -d $(LIBDEST) -f \
    -x 'bad_coding|badsyntax|site-packages' \
    $(DESTDIR)$(LIBDEST)

> The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.

Please do not spread FUD.

They don't have to do any of that. All they have to do is make a virtual environment, which can have any name, and the creation of which is explicitly supported by the standard library. Further, reading the PEPs is completely irrelevant to end users. They only describe the motivation for changes like --break-system-packages. Developers may care about PEPs, but they can get a better summary of the necessary information from https://packaging.python.org ; and none of the problems there have anything to do with Linux system Python environments. The config files that developers care about are at the project root.

Today, on any Debian system, you can install an up-to-date user-level copy of yt-dlp (for example) like so, among many other options:

  sudo apt install pipx
  pipx install yt-dlp

You only have to know how one of many options works, in order to get a working system.

> All they have to do is make a virtual environment

Okay so to create a five line script I have to make a virtual environment. Then I have to activate and deactivate it whenever using it. And I have to remember to update the dependenceis regularly. For my five line script.

Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

I found the whole 'activation' model deeply confusing and annoying. The underlying mechanism of venv is simple and elegant, but the original interface is terrible piece of design.

You, too: please do not spread FUD.

> Okay so to create a five line script... For my five line script.

I can guarantee that your "five line script" simply does not have the mess of dependencies you imagine it to have. I've had projects run thousands of lines using nothing but the standard library before.

> Then I have to activate and deactivate it whenever using it.

No, you do not. Activation scripts exist as an optional convenience because the original author of the third-party `virtualenv` liked that design. They just manipulate some environment variables, and normally the only relevant one is PATH. Which is to say, "activation" works by putting the environment's path to binaries at the front of the list. You can equally well just give the path to them explicitly. Or symlink them from somewhere more convenient for you (like pipx already does for you automatically).

> And I have to remember to update the dependenceis regularly.

No, you do not in general. No more so than for any other software.

Programs do not stop working because of the time elapsed since they were written. They stop working because the world around them changes. For many projects this is not a real concern. (Did you know there is tons of software out there that doesn't require an Internet connection to run? So it is automatically invulnerable to web sites changing their APIs, for example.) You don't have to remember to keep on top of that; when it stops working, you check if an update resolves the problem.

If your concern is with getting security updates (for free, applying to libraries you also got for free, all purely on the basis of the good will of others) for your dependencies, that is ultimately a consequence of your choice to have those dependencies. That's the same in every language that offers a "package ecosystem".

This also, er, has nothing to do with virtual environments.

> Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

Not at all. They are the ones running into the biggest problems. They are the ones who have created, or leveraged, massive automation systems for containers, virtualization etc. — and probably some of it is grossly unnecessary, but they aren't putting in the time to think about the problem clearly.

And now we have a world where pip gets downloaded from PyPI literally billions of times a year.

Reply on news.ycombinator.com