3 ms·

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

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/2ca46a7c27c837adf23ad1e9bcc73a2398f45b9d/Makefile#L162 https://github.com/cbarrick/efiboot/blob/2ca46a7c27c837adf23...

rpier001 3y ago
Out of context (and with limited knowledge) comment 3 seems terrifying.
- cbarrick 3y ago
  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.
stop50 3y ago
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)
jjgreen 3y ago
Don't try running that on Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035546 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035546
- cbarrick 3y ago
  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-sysconfig-are-changing-pip-install-prefix-outside-virtual-environments/18240/34 https://discuss.python.org/t/linux-distro-patches-to-sysconf...
  - jjgreen 3y ago
    Grim. Python packaging is a skip (dumpster) full of dead rats.

rpier001 3y ago

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

cbarrick 3y ago
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.

stop50 3y ago

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)

jjgreen 3y ago

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

cbarrick 3y ago
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-sysconfig-are-changing-pip-install-prefix-outside-virtual-environments/18240/34 https://discuss.python.org/t/linux-distro-patches-to-sysconf...
- jjgreen 3y ago
  Grim. Python packaging is a skip (dumpster) full of dead rats.