Tweag + Nix Dev Update #4

It has been some time since our last update, but 2020 happened. We hope to make these updates again more regular, maybe not weekly, but once there is enough things to write about.

This update is going to be a bit long since we need to catch up on quite some things we were working on.

As you might already know, at Tweag we are working hard to make Nix better and do our very best to complement the rest of the community efforts. A lot of our work is open sourced and here are most notable results from last few weeks.

Nix: Lazy attribute names

Silvan is working on implementing lazy attribute names for Nix, which would allow code like

(throw "" // { x = 0; }).x
-> 0

to work.

There were initial doubts whether this could be done without decreasing performance, but measurements from the latest implementation reveal no such problems! We heard you like plots? We give you the plot.

0 is the base of this PR, each number is an additional commit

Nix: nix develop multi project support

Eelco added a feature to nix develop command allowing you to develop multiple projects together.

This is primarily useful if you’re developing simultaneously on a package and one of its dependencies. E.g. if you’re hacking on Hydra and Nix, you would start a dev shell for Nix (which installs in e.g. ~/Dev/nix/outputs), and then a dev shell for Hydra as follows:

$ nix develop \
  --redirect .#hydraJobs.build.x86_64-linux.nix ~/Dev/nix/outputs/out \
  --redirect .#hydraJobs.build.x86_64-linux.nix.dev ~/Dev/nix/outputs/dev

Nix: support for project-local nix options

Eelco is working on adding support for project-local Nix options for your flake.nix. This will allow users to configure per-project binary caches and make the experience of entering a development environment even more declarative.

The feature is not yet complete, but a premature snippet of this feature could be this flake.nix:

{
  description = "Very interesting flake";
  config =
    { bash-prompt-suffix = "ďż˝[1;35mngi# ďż˝[0m";
      substituters = [ "https://cache.ngi0.nixos.org/" ];
    };
  ...
}

Nix: Content-addressed derivations (CAS) update

Théophane is working tirelessly on CAS support in Nix.

Main effort is going into evaluating multiple draft implementations for remote cache support in CAS. It seems that there is no perfect implementation, so a tradeoff needs to be made. The proof of concept is now entering a cleaner rewrite.

For introduction to Content-addressed derivations topic please watch his talk from NixCon and consult design document if you wish to know more. Those interested into this topic don’t hesitate to get in touch by joining #nix-cas channel on freenode (IRC).

Content-addressed derivations - Théophane Hufschmitt

Nix: Marketing

Nix has a marketing team. We wrote about it and Rok did a NixCon talk on why this topic is important.

Rok was working hard finalizing the redesign work for https://nixos.org that started already in September. All pages received much needed refresh (Download page, Learn page, Community page, Governance and Donate page), with the Features page still waiting for the content to be finalized.

Don’t forget to say hi to the marketing team in their IRC channel #nixos-marketing on freenode.

Nix: Misc

Nickel

I think most of you have heard about Nickel by now. If you haven’t please check NixCon talk about it and a recent blog post. Yann is the brains and muscles behind it. His focus this year is bringing Nickel to the point where one could start playing with it and discovering its potentials.

Highlights of the last few weeks are:

We would like to invite you to help us shape Nickel’s syntax in the Bikeshedding Dojo

If all of the above itched your curiosity come and check it out on GitHub and feel free to check in on the #nickel channel on freenode.

“Top secret” project

Adam is working on a “top secret” project which he hopes to announce soon - so not that top secret really :smiley:. The project will be - in a few days - open sourced and we hope that it will put Nix another step closer to the mainstream adoption.

And yes I wrote this as a teaser, since I just couldn’t help myself as I’m too excited about it.

Thank You

As a last thing we would like to say ”Thank you” to the community. We appreciate and value a lot all the efforts from the community. We know we wouldn’t be where we are if it wouldn’t be for you. We hope our contributions also make your job easier. And most importantly thank you to all of you who make contributing to Nix fun!

25 Likes

“Put Nix another step closer to the mainstream adoption”, do we have another hint?:thinking:

And I am looking forward to lazy attribute names!

1 Like

What’s the idea for the UI with respect to administrator-only (security scary) settings such as which keys to trust for substitution etc? Launch an editor with sudo, or instruct the user on what’s necessary to ask of the system admin? The former might be nicer for single users, while the latter is likely more useful for multi-user systems.

1 Like

What’s the idea for the UI with respect to administrator-only (security scary) settings such as which keys to trust for substitution etc?

Currently you can’t set binary cache keys in flake.nix yet. In the future this should probably be trust-on-first-use, i.e. you’ll be prompted whether you want to trust a new key.

1 Like

Currently you can’t set binary cache keys in flake.nix yet. In the future this should probably be trust-on-first-use, i.e. you’ll be prompted whether you want to trust a new key.

I was more curious about how the UX will work on multi-user setups. Like, I wouldn’t want another user on my system to be able to make a dangerous, untrustworthy substituter able to inject store paths on the shared system, so how does one go about saying “yes, users can choose to TOFU this key”? I imagine it’d have to be a global list of trusted but disabled keys in/etc/nix/nix.conf – that is, like trusted-substituters but for keys.

The user will have to be in the list of trusted-users of the Nix daemon (at least until we have content-addressable Nix).

that is, like trusted-substituters but for keys.

That option already exists, namely trusted-public-keys.