-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Extensible attrsets #2511
Comments
So I was thinking some more about extensible attrsets and noticed that they could actually be implemented almost completely in pure-nix as of today, I think. As a proof, here is an example implementation and use: https://github.com/Ekleog/nix-extensible-attrsets/blob/master/example.nix (disclaimer: it was done in ~2h30, is completely imperfect, likely has bugs and was intentionally kept as simple and readable as possible. IOW, it's a POC) The two features missing for a nicer usage are:
The advantage is that if these two features are implemented (and not directly extensible attrsets), then we get smaller primitives, and thus more unexpected features that will be usable later. For instance, the metadata format is completely extensible and easily introspectable (just access the Also, we gain agility should we notice that the module system is not actually what we want, as if the module system is directly embedded into nix then we could never remove it unless we're willing to break all the packages (including those unrelated to nixpkgs). |
There are many orthogonal problems described in @edolstra gist. One of them is adding "configurations" (or "modules", or "extensible attrsets") to Nix syntax, another is to rewrite If you think your approach covers "extensible attrsets" requirements, then you can try to rewrite I somewhat like
and teach Nix parser to parse |
Why not move the gist to an official RFC? |
It's not in a state yet to be turned into an RFC. |
@danbst The main reason why I didn't move forward with |
On extensible attrs I'd like to reference Russell O'Connor on fake dynamic binding in Nix:
As noted by @edolstra in NixCon talk, making |
The About performance, Nix will have to call into the As we're talking about a redesign of the way the whole nixpkgs ecosystem works, that will likely break lots of stuff, I think getting ourselves locked up in specifics (by making nix implement them before we even start migrating) would be more harmful than first keeping nix ext-attrset-agnostic (with just late-bound sets and metadata syntax -- two orthogonal features), then porting nixpkgs and tweaking our ext-attrset implementation, and finally, once it has stabilized and we're happy with it, integrate the resulting ext-attrset idea in nix -- if it can indeed bring significant speed/memory gains. |
@Ekleog isn't there a problem that migrated Nixpkgs might be too slow to evaluate without direct Nix support for the new features? |
It is a risk indeed, but to be honest I don't see much that Nix could do
to optimize this, apart from storing the argument names for the value
functions at a centralized place.
My understanding of the current performance issues, that I haven't
validated by checking the implementation yet, is that the cost resides
in having to evaluate the behemoth `stdenv.mkDerivation` for every
single derivation, which this proposal would already alleviate.
If performance actually significantly drops, I think it will mean that
the idea that this proposal would make nixpkgs faster if included in Nix
will have been a mistake we would all have made, because including in
Nix doesn't have *that* large an optimization possibility, AFAIU :)
|
Also see my critique of https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d in NixOS/nixpkgs#56227 (comment) where I argue that 80% of the problems it tries to address can be solved by simply adding optional types to attrsets and |
If I read correctly, the latest flakes proposal has changed to no longer actually include extensible attrsets: https://github.com/NixOS/nix/blob/b0fc5bcee9f74c717d8ca564c193a5ad7846e5c7/doc/flakes/design.md (side-note: I personally like that new design much more than the one linked in the top-post) If I am not mistaken, then I think this issue can be closed, as extensible attrsets are no longer under discussion. (not closing myself for now as maybe flakes and extensible attrsets are under parallel discussion) |
I marked this as stale due to inactivity. → More info |
Well, let's close I guess |
This issue is here to track discussion on extensible attrsets.
See https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d (linked with @edolstra's permission) for more details.
cc @matthewbauer @joepie91 @jwiegley @danbst who commented on the gist
The text was updated successfully, but these errors were encountered: