What's the status of the single package fixpoint proposal?

I… don’t like the current situation with mkDerivation. While it might be okay for packaging stuff in nixpkgs, overriding is super inconsistent, and while RFC 92 doesn’t seem to be moving anywhere, dynamic derivations ARE going to get finished at some point, and I would love for nixpkgs to be able to properly represent those. I’ve recently stumbled into the single package fixpoint PR, and was wondering whether it was abandoned or the efforts would be continued at some point, seeing as roberth is on the SC now, which I would expect would accelerate the development

4 Likes

Hi @WeetHet, nice handle, and thanks for asking!

I haven’t managed to complete it due to other projects, but I’d gladly un-abandon it if more people want to get involved with this.
I could do a rebase and perhaps make the layers overridable.

roberth is on the SC now

I’d prefer not use authority for technical decisions / design decisions that can be made in the usual ways. (not sure if that’s what you’re asking)

The SC can get things unstuck by asking questions, resolving conflicts, calling attention to important subjects.
Until we do that though, we need to get some other issues sorted, and it’d have to be part of a broader roadmapping or prioritization effort.

It might well be that such an effort would elevate this issue and PR, but let’s not wait for that.

Also I think there’s plenty of dynamic derivation experimentation that can be done without this PR.
A package attrset can be quite minimal, despite all the (stupid) mkDerivation noise, so it’s quite feasible to construct one, especially if you don’t try to add overriding to it.

7 Likes

Thanks for responding so quickly! I’m probably not skilled enough to work on this, even though I would love to. Would love to have a roadmap including this in the future. I understand that the current situation is very difficult in that a lot of questions need to be resolved to bring the ecosystem to a state where roadmapping can be done successfully, so no pressure here. Dynamic derivations are probably not due for yet another couple of years anyway :sweat:

1 Like

I don’t want to scoop the conference talks announcement too much, but I’m gonna be talking about actually using dynamic derivations. :slight_smile:

11 Likes

I did try hacking on it but realized I was a bit out of my depth with understanding what was going on quite quickly :sweat_smile:
if there are some simpler things that could be attempted, I’d gladly give it another shot(is there a not super complicated generic-builder.nix anywhere?)

Porting a generic-builder.nix to it will change the ecosystem’s interface, at least until we figure out patterns for trying to be 99% compatible, but I’m not sure that should be a goal, to have function attributes like overridePythonAttrs instead of a single new one that allows changing all the internal package attributes.

Maybe the meson code qualifies as a generic builder? I intentionally did not preserve the meson code in mkDerivation when extracting the makeDerivationArgument helper function, so that would have to be added back in layer form, i.e. layers.meson.

These NixOS/nix layers were also sort of anticipating this but use mkDerivation layers. They could easily be ported to mkPackage + layers.derivation + layers.meson. (or just mkPackage + layers.derivation in case of the fileset layer)