The Nix community doesn’t have an official roadmap. Everything that we have achieved so far has been done trough individuals picking stuff up on their own. It’s quite amazing if you think about it.
On the other hand it’s a bit hard for non-core contributors to find out what is happening. I believe there are a bit of lost opportunities for collaboration as well.
In that spirit, I want to try something new here; set some personal goals for the next release. Nobody is directing anything here, it’s just me trying to commit to something for the next release. The idea is to give me focus and also broadcast to others that might want to join the effort.
My goal(s) for 19.09
- Have a 1.0 release of
nix-fmt (doesn’t exist yet)
What are your goals?
Rules for this thread
- feel free to edit your post with new goals if they change
- one post per person, start new threads if you want to discuss a topic.
Daily-drive, popularize and present my nix-on-droid clutchfest. It sure won’t grow big for 19.09 release, but by the time I aim to consult with the others and decide for myself whether it’s worth 1) supporting (at all), 2) including it into F-Droid, 3) mainlining in nixpkgs or keeping separate akin to nix-darwin and/or 4) hosting it officially.
Properly testing whatever I’ve submitted to nixpkgs prior to the release so that the others won’t have to fix that for me.
Meet all you awesome fellows at NixCon and become more involved with NixOS in general.
Some points we’re interested in and at the very least playing around with at Mayflower:
OpenSSL 1.1.1 as default
GCC 9 as default
strictDeps = true for everything
Networking defaulting to systemd-networkd
NixOS-Container improvementes (also in NixOps)
__structuredAttrs = true(?)
further cross fixes
I’m working on making the Ruby support in nixpkgs better:
- Provide a simple way to use
nix-shell with most popular ruby gems without bundler/bundix similar to Haskell and Python
- Automate updates
- Run regular security checks
- Try to foster a larger Ruby&Nix community
- Maybe rewrite bundix to be easier to use and understand
- Actually test all the gems with all ruby versions automatically
I think most of this can be done before 19.09 hits, I already started work on it in ruby: add ruby.withPackages by manveru · Pull Request #61114 · NixOS/nixpkgs · GitHub
Once I’m done with that, I’ll probably try to also do something similar for Elixir, but at least I’d like to package some applications like Pleroma and see how that goes.
I’d very much like to work on changing the default value of
true (and ideally deprecating the option entirely). The current default of
false has been a recurring cause of headaches in working on Home Manager.
Things I may or may not get around to but will try:
- a better let’s encrypt solution that supports dns challenges, ideally using certbot
- track down services which don’t use journald for logging and if possible have them start using it; if not possible to use journald ensure they are rotating logs
- add ensureDatabases and ensureUsers options to the postgresql module and then utilize these new options in modules which provision their own postgresql databases
- cleanup the httpd module & subservices
Things I hope everyone can work toward together:
- zero hydra failures for 19.09!
- fewer abandoned modules and packages in nixpkgs and NixOS
- take advantage of security features that systemd offers in more modules
And finally things I can dream for:
- a basic web testing framework integrated with nixos tests so that web based modules like nextcloud, redmine, etc… can perform comprehensive tests above and beyond checking if a web page is reachable
- propagate software kernel dependencies, or at least check the kernel configuration is ok
- out of the box multipath TCP experience (via a module)
- improving the lua ecosystem (make everything converge basically)
- my neovim config generator with type checking, per project adaptability (you pass some packages to it and it creates a neovim config to develop on these packages)
What I would like to see/work on:
- improve the jupyter module, especially the ability to combine several kernels, the ihaskell one in peculiar (there are a few open issues)
- imporvements on some nix features/UI for persistent shell, remote builds
- shell completion while doing
$ nix-shell -A, it’s annoying to miss the completion precisely when we need to test the software.
- fix neovim functionaltests
- some kind of convergence/convention between nixpkgs and home-manager. Currently some modules are duplicated across the 2 projects.
My goal is to improve the way Agda and Agda libraries are packaged. I’d like the libraries to use the
.agda-lib stuff that’s been around since 2016, and I’d also like there to be a
Agda.withDefaults in nixpkgs
Nixpkgs: Reduce PR count. Can use more community effort and automatic testing.
Improved support for public/private keys generated on remote machines.
Improve statefile support for teams.
Systemd wrapper to allow any NixOS service to be distributed as a disnix-service.
Explore the intersection between dydisnix and Kubernetes.
Would it make sense to update some packages (in the git repo) automatically if they build and pass some tests?
Mainly improvements that I would like to see for the data science/python community that I will be working on.
- normalize all python package names (so they are predictable)
- integrate jupyter kernels/extensions from the withJupyter project
- I have been writing several parser/ast transformation tools for other projects. I would like to learn how to write a code formatter/source code transformer. I have a python project in the works that would automate git commits along with source code transformations in nix (with the intention of making nixpkgs maintenance easier). To automate tasks such as alphabetize package names, check meta values, and ensure https links etc.
We have a significant bot that automatically updates, tests and files PRs with that. It’s currently the most active “contributor” by commit count, too. Automatic merging has been discussed multiple times, but I personally don’t think that’s worth it. Checking upstream announcement and pushing a button feels sufficiently easy when there’s interest.
Well, we don’t have a uniformly recorded list of the most important reverse dependencies to test, and for some of the leaf applications it would be helpful to have end-to-end installed-tests. So what the update bot does automatically is not the whole story. Checking upstream announcements is also not an atomic action yet, but hopefully this gets better soon.
I’d like to update some of our old packages that are stuck on old versions. Ideally, the “default” attribute for every package would be the latest stable version of the package. There’s nothing necessarily wrong with having older versions in Nixpkgs as well, but we should always be working towards using the latest software as much as possible. This will be my main goal for 19.09. I have a meta issue tracking this if anyone wants to help out:
Our goal (with Robert) is to:
- improve tooling for documenting Nix projects (mostly outside of nixpkgs tree)
- open source a few tools that help with day-to-day team development
At ZuriHac, unless I get nerd sniped, I’ll work with Niklas to get statically linked musl executables support into nixpkgs.
re LE dns challenges: we’re using a module for acme.sh internally, it would be nice to see upstream at some point, maybe you’d like to collaborate on this?
Thanks for the link! When I get around to this I’ll message you about it.
I want systemd 242 in. This is what I’ll mostly be working on the coming month.
Things I’d like to make headway on:
(would be happy to talk about the above on freenode/#nixos-wg-ai)
Things I’m ambiently thinking about:
- Integrating configurations managed by external applications with nix (home-manager)
- Generally standardizing things across nixpkgs
- UX improvements