Tweag+Nix dev update #42

Development
1

We reached the H2G2 update :tada: (related to 42, explanations)

Previously in Tweag :eyes:
Next in Tweag

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

Documentation :books:

jupyterWith improvements

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

Making Nix ubiquitous :rocket:

Blog posts and media :newspaper:

Nickel

  • @ebresafegaga added types and documentation to the LSP auto-completion engine (#966):

784×372 26.2 KB

  • @ebresafegaga didn’t stop there, and opened a PR to support imports and allow for cross-files actions (#993)
  • @matthew-healy implemented symbolic strings (#994), a feature we came up with to emulate Nix string context in Nickel. See the original proposal for more context. Here is an example of using it with Nickel-nix.
  • @vkleen is squeezing Terraform to get all of its provider information and enrich the corresponding Nickel contracts (#18) for Terraform Nickel.
  • @vkleen continued to improve the handling of Terraform computed fields in Terraform Nickel.
  • @yannham updated the vim-nickel plugin to the latest syntax.
  • The team cleaned up previous draft work on Nickel-Nix which builds a simple C hello world (#10). We also wrote a simple devshell launching bash (to come in the next PR) without resorting to mkShell on the Nix side. The idea is now to write a library of builders, configurable building block for devshells (think NixOS module), which rely solely on derivation on the Nix side. Our goal is that writing devshell in Nickel will just be combining/enabling builders in a natural way, like configuring NixOS, but relying on Nickel’s native merging and overriding system.

:computer: may Nix be the answer to the question about Life, the Universe and Everything :lack_of_towel_emoji_here:

14 Likes
2

I love that while a Nixpkgs-like codebase is seen as a mandatory use case for Nickel, other use cases are also being considered and experimented with well before 1.0. That seems like a great way to ensure that Nickel is not just feature-complete for Nix users, but flexible, accessible, and useful to newcomers (or even skeptics) to the Nix ecosystem.

Personally, I’d love to see some Nickel support for Nix-less, Docker-centric tools that currently use other configuration DSLs, like Concourse and Dagger. Or imagine it someone new to the Nix universe some day saw Nix+Nickel introduced to their team, but they felt like they had a head start because their company’s GitLab instance used .gitlab-ci.ncl instead of .gitlab-ci.yml!

There’s this tension between simplicity and power in configuration languages that I think most ecosystems resolve by just completely flipping from a simple-but-not-powerful language to a powerful-but-not-simple one. So it is with Terraform vs. the Terraform CDK, Dagger’s CUE SDK vs. Dagger’s TypeScript, Python, and Go SDK’s, Azure Arm vs. Bicep, etc. With Nix, it’s one language and there’s sort of a gradient between ‘simple configuration’ and ‘programming’. I think Nickel has the potential to fill a sweet spot that we’ve enjoyed in the Nix community but not a ton of other places yet. That could both ease adoption and facilitate integrations for a Nickel-based Nix ecosystem some day.

Anyway I love to hear about the experiments for using Nickel to do things like write Terraform configurations.

It’s also great that the experimental new Nix installer supports the Steam Deck! I think users of other ‘immutable Linuxes’ like SteamOS 3, Fedora Silverblue, and openSUSE MicroOS are likely adopters of NixOS. Letting them easily use Nix on their existing distros is a win!

3

I didn’t use nix-installer on my Deck, but you would need to turn the disk protection off (enabled by default so you can’t mess with the system), I’m not sure the system remains much immutable after changing it.