Hello 
Previously in Tweag 
Next in Tweag
Making Nix solve people’s problems
-
@fricklerhandwerk passed on leadership of the documentation team to @lucperkins (Determinate Systems). He will collaborate in the background on the common goal of empowering contributors and maintainers to continue improving documentation.
-
As part of their work on the Nix team, @fricklerhandwerk and @thufschmitt continued working on establishing a vision for Nix
-
@thufschmitt reviewed and discussed the RFC 136 about the stabilization of Flakes and the new CLI
Documentation 
jupyterWith improvements
- @djacu and @garbas have been working on bug fixes, CI improvements, documentation updates.
- @djacu and @thufschmitt added the OCaml kernel.
- @djacu and @garbas added a website for the documentation.
Making Nix work reliably everywhere 
-
@yorickvp is preparing a RFC for a deprecation process in Nix
-
@solene is trying to figure why shell based testing framework are so slower (related to 7232 and 7135)
Making Nix ubiquitous 
-
A number of community members independently submitted a request for a DevRoom at FOSDEM 2023. One of these got accepted, and @bjth and @thufschmitt helped shaping up the call for presentations. Read more about this
-
@ravendii obtainted data from netlify and google trends to plot some more metrics on the popularity of Nix. The next step is to send the data to a database to be used with grafana, and then get even more data (Twitter?). @solene will work at providing a Tweag grafana instance until the nixos community provides one.
-
@bjth will receive help from @djacu to start the NixTalks series
-
@bjth, as part of the marketing team, published a report of their last meeting
-
@infinisil started his weekly Q&A lecture two weeks ago. We might be able to live-stream this session soon
https://www.youtube.com/playlist?list=PLyzwHTVJlRc8yjlx4VR4LU5A5O44og9in
-
@solene wrote a nice blog post showing how the mostly unknown
specialisationsNixOS feature could be used to compartimentalize your computer
Nickel
Nickel is preparing for a 0.3 release, as we’ve bundled quite a few features (planned by RFC001) since 0.2.1! Since the last update:
- @acaccia implemented string interning for identifiers, improving performances (#835)
- @yannham implemented “push priority” operators, as requested and explained in issue #279.
-
@ebresafegaga got his hands on the LSP:
- He added LSP support for type wildcards. Type wildcards allow putting holes in a static type annotation, asking the type checker to infer them, when you don’t know or don’t care about some parts: for example,
let foo : Num -> _ -> Num = fun x _ign => x+1. The LSP didn’t support them, but now it does (#856). - He landed a long-awaited feature: record fields completion (#867). When typing
foo., the LSP now provides a list of possible field in some cases, iffoois a record. The feature isn’t complete nor battle tested, but it’s a stepping stone for leveraging concretly the static information provided by Nickel through types and contracts.
- He added LSP support for type wildcards. Type wildcards allow putting holes in a static type annotation, asking the type checker to infer them, when you don’t know or don’t care about some parts: for example,
- RFC004 (type inference in the presence of the dynamic type and dictionary types) and RFC005 (fixing a number of defects of the current semantics of merging and metadata) have been merged!
- @vkleen is working on using Nickel for Terraform deployments. Check out his tf-ncl repo(WIP), it’s pretty cool! A Nix expression get the provider’s schema automatically and convert it to a Nickel contract on the fly, that you can use in your config file. All you have to do is to write your config in Nickel. Together with a solid record completion and in-LSP contract checks (we’re not there yet), this could make for a very nice development experience.
may your build be reproducible (and painless) 
