| 5 Nov 2023 |
adisbladis | Yes and no.. | 03:45:52 |
adisbladis | Nixpkgs is stuck with it's crummy manual packaging, and I don't see any way to push any kinda sanity forward there | 03:46:27 |
K900 | Because that way we can just point at the out-of-tree thing and say "do you want to simply build your own thing? use that" | 03:46:38 |
K900 | In reply to@adis:blad.is Nixpkgs is stuck with it's crummy manual packaging, and I don't see any way to push any kinda sanity forward there I think there's value in unvendoring dependencies the way nixpkgs does | 03:47:04 |
adisbladis | We're stuck with poorly translating upstream package definitions to nix and losing fidelity in the process | 03:47:05 |
K900 | But I also don't think most people that just want to ship stuff should go that route | 03:47:20 |
adisbladis | In reply to @k900:0upti.me I think there's value in unvendoring dependencies the way nixpkgs does Absolutely, there is very different needs for packaging stuff out of tree and in tree | 03:47:48 |
K900 | Like, it's very much a distribution thing | 03:47:55 |
adisbladis | But like, why do we poorly translate pyproject.toml files into nix | 03:48:00 |
K900 | Because we can't do IFD well, mostly? | 03:48:17 |
K900 | Like I think pyproject.nix would be great in nixpkgs | 03:48:35 |
K900 | If we figure out a way to do IFD without exploding | 03:48:48 |
adisbladis | What I mean is, why is nixpkgs python packages not just a pyproject.toml dumped in tree | 03:48:51 |
adisbladis | In reply to @k900:0upti.me Like I think pyproject.nix would be great in nixpkgs It doesn't use IFD at all | 03:49:04 |
K900 | Well it would if the pyproject.toml comes from the upstream source | 03:49:17 |
adisbladis | What I mean is, instead of having a default.nix in tree we'd have pyproject.toml in tree | 03:49:27 |
adisbladis | The update process would literally be to download the upstream one and dump it | 03:49:46 |
K900 | I kinda like that, but I'm also kinda worried about how to encode the fixups | 03:50:36 |
K900 | Which we're going to need a lot of | 03:50:39 |
K900 | I'm actually about to run myself into a much similar problem with KDE6 stuff | 03:51:00 |
K900 | Because I really want to generate most of it from upstream metadata | 03:51:08 |
K900 | But I'm not sure what a good API for adding fixups on top would be | 03:51:22 |
adisbladis | If you'd take the pyproject.nix approach with an abstract project representation and renderers you could do something like
let
project = load ./pyproject.toml;
attrs = render python3 project;
attrs // {
buildInputs = attrs.buildInputs ++ [ pkgs.openssl ];
}
| 03:53:28 |
adisbladis | Or something along those lines | 03:53:35 |
adisbladis | * If you'd take the pyproject.nix approach with an abstract project representation and renderers you could do something like
let
project = load ./pyproject.toml;
attrs = render python3 project;
in
python3.buildPythonPackage (attrs // {
buildInputs = attrs.buildInputs ++ [ pkgs.openssl ];
})
| 03:54:05 |
adisbladis | * If you'd take the pyproject.nix approach with an abstract project representation and renderers you could do something like
let
project = load ./pyproject.toml;
attrs = render python3 project;
in
python3.buildPythonPackage (attrs // {
buildInputs = attrs.buildInputs ++ [ pkgs.openssl ];
})
| 03:55:34 |
adisbladis | But I think that 90% of the time (just a number pulled out of thin air) you wouldn't need fixups | 03:58:07 |
| 6 Nov 2023 |
adisbladis | Thinking a bit out loud here about a possible interface for lock files:
{ lib, pkgs, poetry2nix, pyproject }:
let
# Stub attrs, not yet implemented
pdm = { };
overlays = { };
# Use project abstraction from pyproject.nix
project = pyproject.project.loadPyproject {
pyproject = lib.importTOML ./pyproject.toml;
};
# Python packages overlay
overlay = let
# Create an overlay from pdm.lock
pdmPackages = pdm.mkOverlay {
pyproject = lib.importTOML ./pyproject.toml;
pdmLock = lib.importTOML ./pdm.lock;
};
# Pdm.lock is not having PEP-517 build systems locked, use overrides from poetry2nix
pdmWithBuild = overlays.intersect pdmPackages poetry2nix.overlays.build-systems;
# Only apply build system overrides to packages that actually need them (packages created by the overlay generator)
in overlays.intersect pdmPackages poetry2nix.build-systems;
# Create an overriden interpreter
python = pkgs.python3.override {
# Note the self argument.
# It's important so the interpreter/set is internally consistent.
self = python;
packageOverrides = overlay;
};
# Render buildPythonPackage with our overriden interpreter
attrs = pyproject.lib.renderers.buildPythonPackage { inherit python project; };
in python.pkgs.buildPythonPackage attrs
| 01:04:38 |
adisbladis | * Thinking a bit out loud here about a possible interface for lock files (cross post from #pyproject.nix:blad.is ):
{ lib, pkgs, poetry2nix, pyproject }:
let
# Stub attrs, not yet implemented
pdm = { };
overlays = { };
# Use project abstraction from pyproject.nix
project = pyproject.project.loadPyproject {
pyproject = lib.importTOML ./pyproject.toml;
};
# Python packages overlay
overlay = let
# Create an overlay from pdm.lock
pdmPackages = pdm.mkOverlay {
pyproject = lib.importTOML ./pyproject.toml;
pdmLock = lib.importTOML ./pdm.lock;
};
# Pdm.lock is not having PEP-517 build systems locked, use overrides from poetry2nix
pdmWithBuild = overlays.intersect pdmPackages poetry2nix.overlays.build-systems;
# Only apply build system overrides to packages that actually need them (packages created by the overlay generator)
in overlays.intersect pdmPackages poetry2nix.build-systems;
# Create an overriden interpreter
python = pkgs.python3.override {
# Note the self argument.
# It's important so the interpreter/set is internally consistent.
self = python;
packageOverrides = overlay;
};
# Render buildPythonPackage with our overriden interpreter
attrs = pyproject.lib.renderers.buildPythonPackage { inherit python project; };
in python.pkgs.buildPythonPackage attrs
| 01:05:06 |
adisbladis | cc K900 ⚡️ | 01:05:19 |