Tweag+Nix dev update #40

Development
1

Hello :v:

Previously in Tweag :eyes:
Next in Tweag

Making Nix solve people’s problems :wrench::toolbox:

Documentation :books:

Opened, merged, and reviewed pull requests

Opened

Merged

Reviewed

Reviewed and merged

jupyterWith improvements

Making Nix work reliably everywhere :penguin::apple::window:

Making Nix ubiquitous :rocket:

Blog posts and media :newspaper:

Nickel

  • @ebresafegaga continued to work on record completion in the LSP: he added completion based on contract information (#914), and completion for the std library is up for review (#918)!
  • @dpl0a is experimenting with incremental computations. The end goal is that when overriding a substantial configuration, we would only recompute the values which atually change (like caching and early cutoff in a build system, but for program evaluation). The first step is a consequent refactoring to decouple the interpreter from an abstract notion of evaluation cache (#916)
  • @yannham fixed a bug in the implementation of recursive overriding (#940)
  • The team continues to experiment with using Nickel to write Nix derivations (nickel-nix future PR). We can build a simple C hello package, and are moving on to have small, modular framework to build shells (not based on mkShell but on a NixOS modules-like approach, thanks to Nickel’s merging system).
  • After bikeshedding sessions (#817, #922), 0.3 is coming very soon!

What’s coming next?

A bit later than ususal because calendar scheduling is a complex art, here are our main plans for the coming weeks:

Making Nix solve people’s problems

  • @radvendii is taking over the work on content-addressed derivations that was left unfinished. The goal is to get it to a state where we can declare them stable in Nix
  • @yorickvP will push forward his RFC on deprecation warnings
  • This has been delayed by some technical issues beyond our reach (namely: Google workspaces making our life more complex than what it should), but @infinisil still intends to live-stream the Nix hours. Hopefully that should be possible in the coming week
  • @yorickvP and @thufschmitt will work on improving the first-time contributors experience, by making sure that the hacking guides are correct and relevant, and that the whole process from cloning to PR is smooth-enough.

Making Nix work reliably everywhere

  • @infinisil will keep working on the auto-calling convention for Nixpkgs packages
  • The work on tests is partially stale since the experiments replacing the current testsuite by an off-the-shelf framework haven’t been convincing enough. We’d like to try other possible improvements and refactorings, but we don’t have a clear plan yet.

Making Nix ubiquitous

  • @bjth and @thufschmitt will keep working on organizing the FOSDEM devroom — reviewing the talk proposals in particular.
  • @bjth and @garbas are also working on restarting the “what’s new in Nix” videos that used to present the new releases of Nix.
  • @radvendii will push towards having his work on the metrics integrated in the official NixOS Grafana dashboard

:metal: build fast and reproducible :vulcan_salute:t6:

17 Likes
2

I am super excited about the recent progress on Nickel!

Whatever its flaws, it’s clear to me that the NixOS-like module interface is the most compelling way to use Nix. It furnishes a porcelain which feels like a ‘dumb’ configuration language that any newbie can read and understand without any programming experience.

The ‘happy path’ UX flowing from that has substantially driven the success of NixOS, Nix-Darwin, and Home Manager. (It’s also what was attractive about Runix at Shopify, if anyone remembers those talks.) Recently, we’ve seen serious efforts spring up in the remaining untouched corners of the ecosystem which place high bets on that kind of module interface: flake utilities (flake-parts) and ephemeral shells (devenv.sh).

It is awesome to see that Nickel is now ready for prototyping similar tools. I’m optimistic that some day very soon, some of these ancillary module systems can become early proving grounds and beneficiaries of Nickel’s merge system!

3 Likes
3

Any work planned on this:
https://github.com/NixOS/nixpkgs/issues/24844

aka the stat storm, i.e. the fact that library loading in nixos is O(n^2) vs O(1) in standard FHS distros.

2 Likes
4

Not that I’m aware of

5

@anonimasu it’s not, but I’d be quite happy to see some progress on that front :slight_smile:

1 Like
6

I have demonstrated GitHub - fzakaria/nix-harden-needed: Bubble up the correct paths to your shared object libraries in Nix and GitHub - fzakaria/shrinkwrap: A tool that embosses the needed dependencies on the top level executable but have not yet applied it to all nixpkgs at scale.

7 Likes