Note from the author: last update was 6 weeks ago, this is unusual. The reason is that I’ve been very sick, not able to work for a while and dispatch my work to my colleagues, including this task. I’m back on tracks 
.
Previously in Tweag 
Next in Tweag
We will have a few people from the team talking at FOSDEM 2023 
(Nix and Nickel)
Making Nix solve people’s problems 
- As part of their work in the Nix maintainers team, @thufschmitt and @fricklerhandwerk reviewed and merged more than a hundred of PRs and issues (here and here).
- This big pull-request by @layus finally made it to master (after a short revert-unrevert roundtrip). Hopefully this will notably increase the quality of the Nix error messages.
- After months of discussion, @infinisil and the Nixpkgs Architecture Team opened the first RFC to improve the nixpkgs architecture. For many cases, this RFC makes adding a new package as simple as creating a directory named like the attribute, without having to find an appropriate place in the
pkgscategories andall-packages.nix.
Documentation 
jupyterWith jupyenv updates
- We celebrate the new name of the project: jupyenv!
- The new site can be found at https://jupyenv.io/
-
This big pull-request by @garbas and @djacu has finally been merged to
mainand brings significant improvments to the project.- jupyenv now use NixOS modules to enable and configure kernels. You can find all configurable options here.
- This update is released as version
0.1.0. We will be making new releases as the project grows to help users specify a particular version and not have to rely on commit hashes. - We have added a blog to the documentation site to communicate when there are new releases, API changes, and bug fixes.
- There is a new Matrix space for users to interact with each other and ask questions.
- You can find a more detailed write up of the latest updates on the Tweag blog.
Making Nix work reliably everywhere 
-
@solene work at improvement message when using an untrusted substituter evolved into documentation writing in
nix.confman page, to clarify information about trusted users and trusted substituters. Nix PR #7641 -
@Radvendii had submitted a pull-request fixing
nix why-dependsfor content-addressed derivations (#7337). Unfortunately, the fix brokenix why-depends --derivation, so @thufschmitt fixed this and added some tests in #7539. - @yorickvp submitted a pull-request (#7721) that fixes a problem where unwanted outputs weren’t being passed to the post-build-hook.
Making Nix ubiquitous
Blog posts and media 
- François Caddet wrote a blog post explaining Nix
with;with Nickel - @thufschmitt and @Radvendii held a couple of meetings with some community members to clarify and expose the different community metrics that we have.
- @djacu introduced Jupyenv in a blog post
- @thufschmitt opened a pull-request to refine the role of the NixOS foundation and the board, as a way to sustain more efficiently the growth of the community
- @infinisil published 5 episodes of The Nix Hour! All episodes now also have a title tagging the mentioned topics, in addition to the more detailed timestamps
Nickel
Announcement: we will be presenting no less than 3 talks in total on Nickel and related projects at FOSDEM + CfgMgmtCamp: Nickel-Nix, Terraform-Nickel and a general talk on the approach of Nickel to configuration. If you plan to be there, don’t hestitate to come and to say hi 
-
@ebresafegaga added a lot of shiny features to the LSP! After the completion for the standard library with documentations and types, he tackled:
- making it work through multiple files/imported files (goto definition/reference, gathering type/contract information, etc.) (#993).
- context completion: when you’re filling a record (attribute set in Nix), and this record has a contract attached, the LSP provides completion. In practical terms, it means while writing something like flake, a derivation, a module, or any configuration, you get the list of possible options, their documentation and their type, which is neat (#1057).
- plus other bugfixing and small improvements.
-
@vkleen continued to work on Terraform-nickel, with a better handling of Terraform’s computed fields, and started to modularize it à la NixOS modules.
-
@yannham implemented RFC005, which fixes a number of issues with the previous semantics of merging and metadata. In particular, the implementation of this RFC was strongly needed by @vkleen for Terraform-Nickel and for Nickel-Nix. (#990, #1086)
-
on the Nickel-Nix front, we previously solved the lack of string context in Nickel (by introducing symbolic strings), and a number of small blockers, allowing us to write our first derivations. Now, @solene and @djacu are coming to the rescue to provide more useful pieces: shell builders. Those are basic composable building blocks (a bit like a NixOS module) that you can easily assemble to make a development shell, without relying on Nix
mkShell. Beside a bit of flake boilerplate (but mostly templated) to use Nickel instead of Nix to write the shell, here is what it takes to make a shell withrustc,rust-analyzerandcargoavailable:let builders = import "builders.ncl" in { output = { name = "nickel-shell", } } & builders.RustShellLooks simple! A bunch of basic builders for language dev environment like that are already written, but need to be merged properly first.
We plan to release Nickel-Nix 0.1 (or Nixel, the bikeshedding is going strong) in the coming week, focusing on the development shells.
build healthy and reproducible software 
