lix-project/lix

Fork 54

Feature detection: `builtins.features` #607

New issue

Open

opened 2024-12-27 13:20:15 +00:00 by raito · 7 comments

raito commented

2024-12-27 13:20:15 +00:00

Owner

We would like to enable feature detection for the "userspace".

Describe the solution you'd like

The structure we could envision is to produce a attrset which would contain things like those:

builtins.features."systems.lix".something

Describe alternatives you've considered

Suffer the same frustrations all the time about builtins proliferation and have userspace suffer.

See prior art like #144.

Additional context

Mentioned in person with @jade.

## Is your feature request related to a problem? Please describe. We would like to enable feature detection for the "userspace". ## Describe the solution you'd like The structure we could envision is to produce a attrset which would contain things like those: `builtins.features."systems.lix".something` ## Describe alternatives you've considered Suffer the same frustrations all the time about builtins proliferation and have userspace suffer. See prior art like #144. ## Additional context Mentioned in person with @jade.

jade added the

Context

RFD

Area/language

labels

2025-01-07 17:23:55 +00:00

roberth commented

2025-03-10 08:52:22 +00:00

Member

A builtins.features as an attrset would permit attrNames builtins.features, which would be another source of entropy and another temptation to put more info in derivations, but this can be mitigated.
Instead, it could be a function to bool, example:

builtins.hasFeature "systems.lix.something"

Returning a bool may or may not be required. I'd lean towards specifying that the type may depend on the string, but I suppose we'll have lots of bools.

A `builtins.features` as an attrset would permit `attrNames builtins.features`, which would be another source of entropy and another temptation to put more info in derivations, but this can be mitigated. Instead, it could be a function to bool, example: ```nix builtins.hasFeature "systems.lix.something" ``` Returning a bool may or may not be required. I'd lean towards specifying that the type may depend on the string, but I suppose we'll have lots of bools. Related discussion: https://github.com/NixOS/nix/pull/5971#issuecomment-1021695124

jade commented

2025-03-10 16:24:25 +00:00

Owner

Hmmm. On the other hand, an attr set is nice because it's discoverable, though this is a temptation as you've mentioned.

It could be a useful compromise if the features list is directly in the documentation string of the function, I suppose. But I also think each feature should have its own little paragraph describing what it is, when it showed up, and similar. I wonder how we could expose that ergonomically to the repl use case.

Hmmm. On the other hand, an attr set is nice because it's discoverable, though this is a temptation as you've mentioned. It could be a useful compromise if the features list is directly in the documentation string of the function, I suppose. But I also think each feature should have its own little paragraph describing what it is, when it showed up, and similar. I wonder how we could expose that ergonomically to the repl use case.

lix-bot commented

2025-05-06 20:07:36 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

comment in cl/3083 ("libfetchers: Add fetcher for the Pijul VCS")

This issue was mentioned on Gerrit on the following CLs: * comment in [cl/3083](https://gerrit.lix.systems/c/lix/+/3083) ("libfetchers: Add fetcher for the Pijul VCS")

rbt was assigned by jade

2025-06-10 22:28:51 +00:00

rbt commented

2025-06-10 22:41:59 +00:00

Owner

+1 for builtins.hasFeature, this is the approach that Vim uses and it works really well.

+1 for `builtins.hasFeature`, this is the approach that Vim uses and it works really well.

raito commented

2025-06-10 22:46:39 +00:00

Author

Owner

Isn't builtins ? x already it, in the end?

Isn't `builtins ? x` already it, in the end?

roberth commented

2025-06-10 22:54:06 +00:00

Member

Often is, but not for everything. Some things are more subtle, like improvements to a builtin.

Also syntax extensions, in case users want to report nice errors in some central entrypoint file like flake.nix or /default.nix or whatnot, and they don't use the extension in those entrypoints.

I'd recommend against putting store level stuff in here, because that would end up requiring things like querying the remote builders and it breaks the nix-instantiate -> nix-store -r flow, where conceptually nix-instantiate doesn't have builders, esp. if IFD is disabled.

Often is, but not for everything. Some things are more subtle, like improvements to a builtin. Also syntax extensions, in case users want to report nice errors in some central entrypoint file like `flake.nix` or `/default.nix` or whatnot, and they don't use the extension in those entrypoints. I'd recommend against putting store level stuff in here, because that would end up requiring things like querying the remote builders and it breaks the `nix-instantiate` -> `nix-store -r` flow, where conceptually `nix-instantiate` doesn't have builders, esp. if IFD is disabled.

jade commented

2025-06-11 01:13:00 +00:00

Owner

The purpose of hasFeature is indeed for if we fix builtins. For example, without using either nixVersion (on CppNix only! we neutered ours) or using getFlake as a proxy, it's impossible to tell from nix code if the version of fetchTree contains the bug where it will throw an uncatchable error if flakes are disabled rather than not be present, or if flakes are enabled and it works fine.

That is, it's for builtins having changes in having more accepted arguments.

Also btw y'all were thinking of doing a similar neutering of builtins.nixVersion as the one we did but I think it fell through the cracks since 2023. Might want to revive that along with the port of this once we land it.

Store level stuff is complicated for sure. I'm not sure what to do about that as it's definitely something that presents a problem for compatibility but it's impossible in the current protocol to probe and besides, eval and build are often separate. It's out of scope for this one, either way. The purpose of hasFeature is indeed for if we fix builtins. For example, without using either nixVersion (on CppNix only! we neutered ours) or using getFlake as a proxy, it's impossible to tell from nix code if the version of fetchTree contains the bug where it will throw an uncatchable error if flakes are disabled rather than not be present, or if flakes are enabled and it works fine. That is, it's for builtins having changes in having more accepted arguments. Also btw y'all were thinking of doing a similar neutering of builtins.nixVersion as the one we did but I think it fell through the cracks since 2023. Might want to revive that along with the port of this once we land it.

jade added this to the API Versioning project

2025-07-07 00:29:09 +00:00

jade referenced this issue

2025-07-07 00:38:17 +00:00

Versioned output like --json=lix2025 for all json output from Lix #901