Consider API versioning of built-in builders #902

New issue

Open

opened 2025-07-07 00:47:11 +00:00 by jade · 0 comments

jade commented

2025-07-07 00:47:11 +00:00

Owner

This is a really thorny problem: #843 (comment)

To clarify why we in particular are very very unlikely to add more builtin derivation builders, they present a huge versioning problem as there's no way to know which lix or cppnix that the derivation might wind up getting built on at evaluation time, so they are absolutely impossible to feature detect.

This level of interface stability problem is not something we are comfortable introducing without a good reason, and these derivations do already exist in nixpkgs.

And indeed, a symlink function does need to be a built-in builder, not a function, because I believe there's some technical limitations that mean that functions run on the client like builtins.toFile aren't allowed to produce dependencies on derivations. If you try putting ${hello} into the content of builtins.toFile, it will fail.

In any case, for interface stability reasons, I think this is very unlikely to happen as there are viable alternatives.

Currently we have very few built-in builders. This doesn't need to change.

However, for use cases like @puck has for zilch for creating directory trees from Nix language, we might have reason to consider more built-in builders instead of admitting further misuse of weird libarchive features in builtin:fetchurl.

The major blocker on doing that is the versioning implications, since there is absolutely no way to version detect these because of the existence of remote builders. Even so, I think that we probably want to think about how we can version these, even if actual usages are going to need to have a sizeable lead time after getting into a release.

This is a really thorny problem: https://git.lix.systems/lix-project/lix/issues/843#issuecomment-12575 > To clarify why we in particular are very very unlikely to add more builtin derivation builders, they present a huge versioning problem as there's no way to know which lix or cppnix that the derivation might wind up getting built on at evaluation time, so they are absolutely impossible to feature detect. > > This level of interface stability problem is not something we are comfortable introducing without a good reason, and these derivations do already exist in nixpkgs. > > And indeed, a symlink function does need to be a built-in builder, not a function, because I believe there's some technical limitations that mean that functions run on the client like builtins.toFile aren't allowed to produce dependencies on derivations. If you try putting ${hello} into the content of builtins.toFile, it will fail. > > In any case, for interface stability reasons, I think this is very unlikely to happen as there are viable alternatives. Currently we have very few built-in builders. This doesn't need to change. However, for use cases like @puck has for zilch for creating directory trees from Nix language, we might have reason to consider more built-in builders instead of admitting further misuse of weird libarchive features in `builtin:fetchurl`. The major blocker on doing that is the versioning implications, since there is absolutely no way to version detect these because of the existence of remote builders. Even so, I think that we probably want to think about how we can version these, even if actual usages are going to need to have a sizeable lead time after getting into a release.

Rows
Columns