Hacker News Reader

Comment by cbarrick | Hacker News Reader

With project.toml, the new strat is to build the wheel with `python3 -m build` and then install it with `pip install --root=$DESTDIR` plus a handful of flags to tell pip not to touch the network or the local cache.

It's not great, but it's also not terrible.

E.g. https://github.com/cbarrick/efiboot/blob/2ca46a7c27c837adf23...

View on HN

I know that now, but at the time i migrated i didn't and i had the same problems as the post. I still have my problems with using python in the company but it isn't from python or its ecosystem itself. Its from redhat splitting their python packages into the different supported python versions(package a is only available for 3.6 and package b only for 3.11)

Don't try running that on Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035546

Oh wow, this is a pretty gnarly issue for the Python packaging story, considering the looming deprecation of setup.py.

I traced the discussion to [1], which is an interesting read, but it seems that progress on this died out in April, at least on the Python side.

[1]: https://discuss.python.org/t/linux-distro-patches-to-sysconf...

Grim. Python packaging is a skip (dumpster) full of dead rats.

Out of context (and with limited knowledge) comment 3 seems terrifying.

I assume you mean this part:

> We will clobber any previously installed version of this package, even if it breaks whatever else is installed. It's the user's job to make sure that is all sorted out ahead of time.

But this is a `make install` recipe, and I think this is generally expected behavior when running that command. Typically, this would be run in a chroot when building a package.

Reply on news.ycombinator.com