https://github.com/NixOS/nixpkgs/pull/148028
We do a new version every two weeks (now every three weeks during the holidays). Our company is not really nix friendly, but we have a few nix users that want to spend some company time to make our tooling available for the nix community. Do you think it’s a bit too much if I push new versions every two weeks, and should we maybe consider having our own repo for our nix setup?
Also I’d love to help with reviews, I think nix is one of the most important projects I’ve found in the past few years.
Mac users please check this:
https://github.com/NixOS/nixpkgs/pull/151219
simple one 
https://github.com/NixOS/nixpkgs/pull/150431
https://github.com/NixOS/nixpkgs/pull/148637#issuecomment-997275026
This PR adds GRE network tunnel support to NixOS. It has already been reviewed and is ready for merging. Thanks!
Small one, fixing a build problem in rust-analyzer for vscode on Darwin:
May I get eyes on this PR? katago: 1.9.1 -> 1.10.0 by OmnipotentEntity · Pull Request #149680 · NixOS/nixpkgs · GitHub
Hi! I have two MRs pending, and they are my first:
- Napari image viewer. It’s a viewer that lets you e.g. read float32 pictures, or apply colormaps to grayscale images via gui. This PR turned rather noise, because of a number of new dependencies and that napari is split into several packages.
-
OpenSfM: a structure-from-motion framework from Mapillary (comparable to
nixpkgs#colmap). Upstream only really distributes it through docker and the build scripts are somewhat unstable, so having it available through Nix - in a composable manner, unlike docker - would definitely bring value
My interest in nixpkgs is to eventually have an infrastructure for scicomp applications, prioritizing projects that do get used in production, but whose build systems are so obscure, that they can hardly be deployed other than with help of docker or Nix. I would expect Nix way to be the preferred one because of composability and additional guarantees.