Symlink Function #843

New issue

Closed

opened 2025-05-30 22:09:19 +00:00 by maxisthespy · 3 comments

maxisthespy commented

2025-05-30 22:09:19 +00:00

home managers mkOutOfStoreSymlink seems to be a really popular use case, however it seems a bit odd that its only available through home manager. It would be nice to have dedicated support for custom symlinks in base lix

Describe the solution you'd like

Exactly how this is implemented will likely wind up requiring expertise and perspective I dont have but the basic interface I would suggest is something like symlink src dst that takes a file and symlinks it to the destination. As an additional bonus it would be nice if it checked for pre existing non symlinked files and automatically moved them to FILE.bak or something like that so that its non destructive.

Im not sure if this is the type of thing that falls under lix's perview but I think it would be a huge help

379c9fb858/modules/files.nix (L81)
here is how hm implements it

## Is your feature request related to a problem? Please describe. home managers mkOutOfStoreSymlink seems to be a really popular use case, however it seems a bit odd that its only available through home manager. It would be nice to have dedicated support for custom symlinks in base lix ## Describe the solution you'd like Exactly how this is implemented will likely wind up requiring expertise and perspective I dont have but the basic interface I would suggest is something like symlink src dst that takes a file and symlinks it to the destination. As an additional bonus it would be nice if it checked for pre existing non symlinked files and automatically moved them to FILE.bak or something like that so that its non destructive. Im not sure if this is the type of thing that falls under lix's perview but I think it would be a huge help https://github.com/nix-community/home-manager/blob/379c9fb858ef9abe92d5590e7502a7c1387c076a/modules/files.nix#L81 here is how hm implements it

qyriad commented

2025-06-20 13:50:05 +00:00

Owner

@maxisthespy the home-manager option creates a trivial builder that runs ln -s. Lix limits builtin builders almost as much as possible (in fact they're not even documented, #864).

We do have builtin functions for file manipulation at evaluation-time, like builtins.toFile, but we don't even have a functions for creating directories, removing files, or renaming files, and these aren't the same kinds of things that home-manager is doing.

This sounds like an issue for Nixpkgs to me.

@maxisthespy the home-manager option creates a [trivial builder](https://nixos.org/manual/nixpkgs/unstable/#trivial-builder-runCommand) that runs `ln -s`. Lix limits builtin builders almost as much as possible (in fact they're not even documented, #864). We do have builtin *functions* for file manipulation at evaluation-time, like `builtins.toFile`, but we don't even have a functions for creating directories, removing files, or renaming files, and these aren't the same kinds of things that home-manager is doing. This sounds like an issue for Nixpkgs to me.

jade commented

2025-06-20 15:41:41 +00:00

Owner

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.

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.

jade added this to the API Versioning project

2025-07-07 00:43:18 +00:00

jade referenced this issue

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

Consider API versioning of built-in builders #902

jade added the

Status

wontfix

label

2025-07-07 00:47:37 +00:00

jade commented

2025-07-07 00:48:32 +00:00

Owner

I think we are going to file this as WONTFIX, but we are aware that there's use cases for better creation of directory trees from nix language. See the description of #902.

I think we are going to file this as WONTFIX, but we are aware that there's use cases for better creation of directory trees from nix language. See the description of https://git.lix.systems/lix-project/lix/issues/902.

jade closed this issue

2025-07-07 00:48:35 +00:00