Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add user-defined extra builtins. #1844

Closed
wants to merge 1 commit into from
Closed

Conversation

shlevy
Copy link
Member

@shlevy shlevy commented Feb 6, 2018

To enable quick iteration on builtin functions, or adding builtins
that aren't suitable for inclusion upstream (due to limited audience
or proprietary code), without the security concerns entailed by
enabling 'allow-unsafe-native-code-during-evaluation', users can now
define a function in a nix expression at the path specified by the
'extra-builtins-file' nix setting (default
$NIX_CONF_DIR/extra-builtins.nix). That function takes a set
containing at least the 'exec' and 'importNative' attributes,
corresponding to the relevant builtins, even when
'allow-unsafe-native-code-during-evaluation' is false, and the result
is available as 'builtins.extraBuiltins'.

See tests/extra-builtins/extra-builtins.nix for an example, and the
nix manual for full details.

To enable quick iteration on builtin functions, or adding builtins
that aren't suitable for inclusion upstream (due to limited audience
or proprietary code), without the security concerns entailed by
enabling 'allow-unsafe-native-code-during-evaluation', users can now
define a function in a nix expression at the path specified by the
'extra-builtins-file' nix setting (default
$NIX_CONF_DIR/extra-builtins.nix). That function takes a set
containing at least the 'exec' and 'importNative' attributes,
corresponding to the relevant builtins, even when
'allow-unsafe-native-code-during-evaluation' is false, and the result
is available as 'builtins.extraBuiltins'.

See tests/extra-builtins/extra-builtins.nix for an example, and the
nix manual for full details.
@shlevy shlevy requested a review from edolstra February 6, 2018 00:19
@grahamc
Copy link
Member

grahamc commented Feb 6, 2018

  • Can you provide an example implementation of a fetcher?
  • Are fetchers adding things to the store subject to hash checks?

@grahamc
Copy link
Member

grahamc commented Feb 6, 2018

re #1841

@shlevy
Copy link
Member Author

shlevy commented Feb 6, 2018

Fetchers aren't trivial... I'm not sure what value would be added by having another example here over what's in primops{.cc/*.cc} or in nixpkgs. Can you expand more?

Fetchers defined in extra-builtins can do hash checks or not, they can respect pure-eval or not, whatever. If you want a more limited interface you can build it on top of this. (of course, anything added to the store will be hash-addressed).

@grahamc
Copy link
Member

grahamc commented Feb 6, 2018

For the first point, I didn't mean to say fetcher, but also I completely missed (due to how short it is!) the example in the test. Very cool!

For the second point, I wanted to be sure a user builtin couldn't lie about the contents of a file and put data in the store where it doesn't belong. From IRC, the answer is no.

Nice!

@edolstra
Copy link
Member

edolstra commented Feb 8, 2018

I much prefer having a plugin config option (see #1841 (comment)). That's also more general because it supports other kinds of extensions (such as new Store subclasses, e.g. S3BinaryCacheStore could be moved into a plugin).

@copumpkin
Copy link
Member

@edolstra it does seem like the laziness @shlevy is talking about in the comments below the one you linked to is appealing. My dream is for builtins.fetchGit to actually depend on git (so the relevant plugin and its git dependency are expressed in Nix), but for Nix not to. A static loadable plugins architecture would force the fetchGit plugin (and its git dependency) to be loaded whenever Nix is loaded.

Couldn't we just support both mechanisms? It does seem appealing to split out the S3BinaryCacheStore as you say, but nothing says that needs to work the same way as the extra builtins, if we don't make a mess in the code by supporting both.

@edolstra
Copy link
Member

edolstra commented Feb 8, 2018

Another issue is that there is no guarantee that the plugins from extra-builtins.nix are compatible. It's up to the user to ensure that the Nix version used by extra-builtins.nix is the same as the caller's. OTOH, with a NixOS option nix.plugins, it's guaranteed that Nix and the plugins come from the same Nixpkgs.

@shlevy
Copy link
Member Author

shlevy commented Feb 8, 2018

Working on plugins now, @copumpkin my first plugin will be one to support extraBuiltins 😉

@shlevy shlevy mentioned this pull request Feb 8, 2018
@shlevy
Copy link
Member Author

shlevy commented Feb 8, 2018

@edolstra True, though that doesn't apply to extraBuiltins defined with builtins.exec.

@shlevy
Copy link
Member Author

shlevy commented Feb 8, 2018

And we have use cases to support besides NixOS

@shlevy
Copy link
Member Author

shlevy commented Feb 8, 2018

@copumpkin https://github.com/shlevy/nix-plugins/tree/nix-2x-plugins has an implementation of extra-builtins on top of #1855, though it doesn't add the setting (you have to use $NIX_CONF_DIR/extra-builtins.nix, but you can set NIX_CONF_DIR so...)

@shlevy shlevy closed this Feb 13, 2018
@shlevy shlevy deleted the extra-builtins branch February 13, 2018 16:23
@copumpkin
Copy link
Member

For anyone following along confused, we got this through #1854 instead.

@shlevy
Copy link
Member Author

shlevy commented Feb 13, 2018

Oops, sorry, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants