| 6 Dec 2023 |
 K900 ⚡️ | Or at least kill most of it off | 20:10:10 |
 jonringer | Well, deprecate it :) | 20:10:13 |
| jonringer | then kill it | 20:10:16 |
 adisbladis | In reply to @jonringer:matrix.org
adisbladis: quoting from here:
I wonder if it would be better to just expose a new mkDerivation helper (e.g. buildPyprojectPackage). I think within this context, it's simpler to expose the PEP-621terminology without having to compound it with the legacy behavior of buildPythonPackage.
I don't like the idea of yet another functional abstraction for building python packages.
It's already confusing enough with what the actual distinction between buildPythonPackage & buildPythonApplication is. | 21:54:43 |
| jonringer | I think it's fine if the python community is moving in that direction | 21:56:18 |
| jonringer | E.g. buildGoPackage -> buildGoModule | 21:56:28 |
| adisbladis | Introducing PEP-621 terminology isn't the main goal here, it's talking about Python dependencies in Python terms | 21:56:33 |
| adisbladis | That's true even for setuptools | 21:56:54 |
| adisbladis | Optional dependencies aren't a new thing in PEP-621, it just provides an interface for it | 21:57:36 |
| adisbladis | Rn buildPythonPackage support for optional dependencies is very ad-hoc | 21:57:48 |
| adisbladis | If anything I would rather see that we deprecate pyproject = false at some future point | 21:58:25 |
| adisbladis | When you think about it in that way introducing a new function becomes a bit silly:
buildPythonPackage doesn't actually have any knowledge of python dependencies | 22:01:14 |
| adisbladis | Adding that knowledge isn't a massive departure like buildGoPackage -> buildGoModule were | 22:02:06 |
| adisbladis | buildGoModule never had to consider how it composes with buildGoPackage, but with another Python abstraction that would be a consideration, Python modules have to interoperate. | 22:03:02 |
| adisbladis | We have this (incomplete) snippet in our docs:
In a `setup.py` or `setup.cfg` it is common to declare dependencies:
* `setup_requires` corresponds to [`nativeBuildInputs`](#var-stdenv-nativeBuildInputs)
* `install_requires` corresponds to [`propagatedBuildInputs`](#var-stdenv-propagatedBuildInputs)
Most of what that PR does is to introduce these things as separate arguments, but just as PEP-621 names instead of naming created by setuptools
| 22:05:46 |
| jonringer | I guess I was thinking more in context of the bigger PR... but maybe a whole paradigm shift would be a bit premature.... There's a lot of legacy with pythonPackages (e.g. packageOverrides, overridePythonAttrs, etc) which I would like to see go away. But that can be shelved for another time. | 22:18:59 |
| adisbladis | In reply to @jonringer:matrix.org
I guess I was thinking more in context of the bigger PR... but maybe a whole paradigm shift would be a bit premature.... There's a lot of legacy with pythonPackages (e.g. packageOverrides, overridePythonAttrs, etc) which I would like to see go away. But that can be shelved for another time. I'm 100% with you :)
I also want to see them go away, but I don't think we can realistically do it in one go. | 22:20:52 |
| adisbladis | The potential interface I described in #272178 (the tracking issue) can coexist with packageOverrides:
python3Packages.buildPythonApplication {
dependencies = [
(python3Packages.requests.overridePythonAttrs(old: {
Allowing us to migrate package by package, and allowing external repos time to adapt
| 22:22:34 |
| adisbladis | * The potential interface I described in #272178 (the tracking issue) can coexist with packageOverrides:
python3Packages.buildPythonApplication {
dependencies = [
(python3Packages.requests.overridePythonAttrs(old: {
Allowing us to migrate package by package, and allowing external repos time to adapt
| 22:22:52 |
| adisbladis | In reply to @jonringer:matrix.org
I guess I was thinking more in context of the bigger PR... but maybe a whole paradigm shift would be a bit premature.... There's a lot of legacy with pythonPackages (e.g. packageOverrides, overridePythonAttrs, etc) which I would like to see go away. But that can be shelved for another time. I'm hoping that we can eventually move to a hook based python interface | 22:23:37 |
| jonringer | In reply to @adis:blad.is
The potential interface I described in #272178 (the tracking issue) can coexist with packageOverrides:
python3Packages.buildPythonApplication {
dependencies = [
(python3Packages.requests.overridePythonAttrs(old: {
Allowing us to migrate package by package, and allowing external repos time to adapt
Agreed. #poetry2nix | 22:27:17 |
| 7 Dec 2023 |
 hexa (PEP725 when) | fwiw: all format ="setuptools" builds can be converted to pep517 builds, since an empty/missing pyproject build-system defaults to setuptools | 01:16:05 |
| hexa (PEP725 when) | so migrating them is just a matter of setting up nativeBuildInputs correctly and replacing the format | 01:16:24 |
| hexa (PEP725 when) | just in case that was unclear | 01:17:01 |
| hexa (PEP725 when) |
Python builds are converging on pyproject
| 01:17:04 |
| hexa (PEP725 when) | * just in case that was unclear, this is regarding | 01:17:15 |
| jonringer | All faith in the python ecosystem has been lost to me with the python2 -> python3 conversion. Many projects has 10+ years to transition and just twiddled their thumbs. Supporting setuptools will be needed until it's somehow EOL or a hard failure. | 01:31:09 |
| hexa (PEP725 when) | setuptools is just deprecating the python setup.py install workflow | 01:31:37 |
| hexa (PEP725 when) | it can be used as a pep517 builder | 01:31:44 |
| jonringer | * All faith in the python ecosystem has been lost to me with the python2 -> python3 conversion. Many projects had 10+ years to transition and just twiddled their thumbs. Supporting setuptools will be needed until it's somehow EOL or a hard failure. | 01:35:02 |
