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
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 services.dbus.socketActivated to 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
Shooting star:
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.withPackages and Agda.withDefaults in nixpkgs
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:
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?