| 29 Jul 2025 |
 Sandro 🐧 | hehe, let me try that | 14:47:59 |
 emily | you could build with python3 and deploy with minimal but I'm also guessing that's hard for a billion reasons | 14:50:04 |
| Sandro 🐧 | that shouldn't be that hard to do but then you have no test coverage if something is missing | 14:58:06 |
| emily | yeah | 15:03:48 |
| emily | well hopefully IfState is going to have end-to-end NixOS tests… right? :) | 15:03:57 |
| emily | not like you can unit test most of the really important stuff there | 15:04:05 |
 Marcel | In reply to @emilazy:matrix.org
well hopefully IfState is going to have end-to-end NixOS tests… right? :) The funny thing is that he did not really had an idea how to implement automatic tests and them I showed him Nixos tests and now there is nix code upstream. But I've already have VM tests in my nixpkgs fork on the ifstate branch | 15:05:00 |
| Sandro 🐧 | diff --git a/pkgs/development/interpreters/python/default.nix b/pkgs/development/interpreters/python/default.nix
index 5d60226aeb9c..8e38fe089aa9 100644
--- a/pkgs/development/interpreters/python/default.nix
+++ b/pkgs/development/interpreters/python/default.nix
@@ -145,6 +145,54 @@
pname = "python3-minimal";
});
+ # Minimal versions of Python (built without optional dependencies)
+ python3Smol =
+ (callPackage ./cpython (
+ {
+ self = __splicedPackages.python3Smol;
+ inherit passthruFun;
+ pythonAttr = "python3Smol";
+ # strip down that python version as much as possible
+ openssl = null;
+ readline = null;
+ ncurses = null;
+ gdbm = null;
+ sqlite = null;
+ tzdata = null;
+ libuuid = null;
+ bzip2 = null;
+ libxcrypt = null;
+ xz = null;
+ stripConfig = true;
+ stripIdlelib = true;
+ stripTests = true;
+ stripTkinter = true;
+ rebuildBytecode = false;
+ stripBytecode = true;
+ includeSiteCustomize = false;
+ enableOptimizations = false;
+ enableLTO = false;
+ mimetypesSupport = false;
+ withExpat = false;
+ withMpdecimal = false;
+ /*
+ The actual 'allowedReferences' attribute is set inside the cpython derivation.
+ This is necessary in order to survive overrides of dependencies.
+ */
+ allowedReferenceNames = [
+ "bashNonInteractive"
+ "libffi"
+ "zlib"
+ ];
+ }
+ // sources.python313
+ )).overrideAttrs
+ (old: {
+ # TODO(@Artturin): Add this to the main cpython expr
+ strictDeps = true;
+ pname = "python3-smol";
+ });
+
pypy27 = callPackage ./pypy {
self = __splicedPackages.pypy27;
sourceVersion = {
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index c0e953a8d19e..14cb4c3e1ef1 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -6578,6 +6578,7 @@
python313
python314
python3Minimal
+ python3Smol
pypy27
pypy310
pypy311
| 16:25:48 |
| Sandro 🐧 | This got me pretty far. pyroute2 is failing for some seemingly unrelated error. | 16:25:48 |
 ElvishJerricco | I'm not 100% opposed to this but I certainly don't like it | 17:36:52 |
| ElvishJerricco | I mean I can think of how to do it with no new features too | 17:37:08 |
| emily | would you like it if we just… made the closures of things small enough that we can use it for everything? | 17:37:15 |
| emily | without the current hacks | 17:37:23 |
| ElvishJerricco | i.e. make a derivation that creates symlinks to everything listed in a ${closureInfo}/store-paths | 17:37:38 |
| ElvishJerricco | that's really not going to happen | 17:37:47 |
| emily | I genuinely think it could! | 17:38:04 |
| emily | what do you think the blockers would be? (we could discuss in the systemd room) | 17:38:12 |
| ElvishJerricco | even if we split binaries from everything else in every relevant derivation (which is a lot of derivations), there's still way more binaries than necessary in a lot of those derivations | 17:38:33 |
| emily | it doesn't have to be a monolithic bin, we do split out individual binaries into their own outputs when necessary | 17:39:02 |
| ElvishJerricco | even still, I don't like the idea of having to carefully watch over every derivation in the initrd dependency tree to make sure that none of them ever leaks something big in for the rest of time. | 17:40:03 |
| emily | we can have a CI test that asserts on the initrd size | 17:40:32 |
| ElvishJerricco | and having code all over nixpkgs to fix a lot of derivations just for the sake of initrd seems like a bad smell | 17:40:36 |
| emily | well, a Hydra one rather | 17:40:36 |
| emily | which is good to have in general | 17:40:41 |
| emily | (we have it for the ISO) | 17:40:43 |
| emily | I don't think so. split outputs and feature flags are there to reduce closure size where it matters. we don't like to do it without strong reason, but packages going into initrd is a strong reason | 17:41:12 |
| emily | and if we can accomplish it without breaking the normal Nix closure mechanism that's better and means that other usecases can also benefit from the reduced closure | 17:41:48 |
| ElvishJerricco | It just seems like a major burden to be putting on nixpkgs that will require a notable amount of manual effort perpetually. I'm opposed. | 17:41:58 |
| emily | I think it's also a burden to not be able to put packages in initrd without them breaking surprisingly because their closures got clipped | 17:42:58 |
| emily | do you have examples of things you think would be hard to split up to achieve the same results make-initrd-ng does? | 17:43:19 |
