Tweag + Nix dev update #33

Hello Nixers :wave:t2:

Some news from the Tweag Nix team:

Community work

Nix implementation

  • @edolstra worked on improving the state of the statically compiled Nix (nix#6707, nix#6708, nix#6709, nix#6710, nix#6714).
  • @edolstra also helped @grahamc (from Determinate Systems) formatting the whole Nix source tree to bring more consistency to the code (nix#6721)
  • Following his work on building NixOS VMs from a Mac machine, @YorikSar started a discussion on system-agnostic builders (nix#6697)
  • @thufschmitt helped @aciceri (from MLabs) to pick-up the stalled work on making Hydra compatible with CA derivations (hydra#1228)
  • @thufschmitt fixed a small leak in the pure evaluation scheme, where ~/foo evaluated to something different depending on the value of $HOME (nix#6698) Unfortunately this seems to be causing some unexpected complications (nixpkgs#179172), so it might require a bit more work.

Communication & documentation


Team structure

Although the NixOS Foundation announcement already indirectly stated it, we announce the departure of @edolstra, who served as a team lead for several years. He is now joining the team of Determinate Systems, where he will keep working towards making Nix greater than ever.


  • @francoiscaddet translated the list library of nixpkgs to Nickel and statically typed it, as a dogfooding exercise and a benchmark for the typechecker (#722).

  • @yannham opened a few general issues about design questions with respect to the semantics of contracts, merging, and typechecking (#710, #724).

  • @yannham opened an issue about field punning, a.k.a. an equivalent to inherit in Nickel (#747). Feel free to chime in and bikeshed!

  • @fuzzypixelz has started an internship on improving performance. He has fixed a quadratic behavior when concatening arrays (#717), added a way to avoid recompiling regex many times (#732), and has started tackling lazy array contracts, a mechanism to prevent array operations that should run in constant time (like head) from being actually linear because of contracts (#749).

  • @yannham added a companion RFC to the specification of the type system, trying to give an approachable overview of the Nickel type system, why it is the way it is, and proposals for improvement.

  • We’ve sometimes casually said that Nickel is close to being a superset of the Nix language. @francoiscaddet is now putting those words into action as he has started to tackle a Nix to Nickel compiler.

  • @yannham presented (again, intially presented at SPLASH 2021) a talk explaning why adding general union and intersection contracts to Nickel is hard at ECOOP 2022, a research conference. You can read the companion blogpost for a condensed version of the paper.

And that’s all, folks


Does this mean Tweag + Nix updates will continue to include @edolstra’s contributions such as this post?


Nope, this one still includes his contributions because he was still working for us until today, but now you’ll have to ask for a “Determinate Systems + Nix update” (but since these Tweag updates have been started by @grahamc while he was working for Tweag, that might very well happen :slight_smile: )


That sounds really great!

From the README:

To join the team, reach out to the Matrix channel.

When I click the link, I can click through and get to, but that gives me a message that says the room doesn’t exist: does not exist.
Are you sure you’re at the right place?

@Infinisil Maybe the room needs to be made public so that anyone can join or something?

The link above is a 404 (github’s octocat-wan-kenobe “this is not the web page you are looking for”)… was it removed? I don’t even see the mentioned by cdepillabout.

Yes sorry, we got a communication mismatch and the org got renamed since yesterday. I’ve updated the post to point to the right link

Yeah so it’s now just the Nixpkgs Team, main link Nixpkgs Team · GitHub, and the Matrix channel wasn’t created yet, this is still a WIP thing, but I’ll kick it off soon :slight_smile:


It’s still not entirely clear what this team should be called actually. I just got some more feedback by @ckie that “Nixpkgs Team” is perhaps too generic. This team shouldn’t be about maintaining nixpkgs for example.

In short this team should be responsible for solving large-scale problems that are too big to undertake for any single person, either because it’s a tough decision or takes a lot of work.

Any arguments for/against calling this team “Nixpkgs team” or “Nixpkgs design team” or other ideas?

Edit: Another idea is “Nixpkgs architecture team”, though that might be conflated with system architecture like “x86_64-linux”

In the end the name doesn’t matter much, but since this is still early it’s very easy to change now, so we should think about it for a bit and pick something good and never change it again :slight_smile:

nixpkgs architecture team?


I prefer the generic name “nixpkgs team”. We don’t have a formal group taking care of nixpkgs as a whole, and that should be a first step. It should be the go-to place to discuss large PRs. I’m sure you will deal with more than just architecture. You can always constrain the team scope by setting goals and agenda, and break out more specific teams with specific names if needed.

1 Like

I ended up deciding on “Nixpkgs architecture team”, it’s been suggested by a couple people, and I think it’s the best fitting name for its purpose.


Announcement made in Nixpkgs Architecture Team Creation

Hosted by Flying Circus.