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?
As already mentioned, I’m working more on updating static-haskell-nix with the intent of moving more or all of it into nixpkgs, and getting Hydra CI it, because otherwise it can quickly break.
be able to join a domain with sssd (and be able to log-in with gdm)
secure boot
For sssd, I played with it in the past. I think I was able to log-in with the console but not with gdm. I’m not sure I could pull it off but I might try again.
I’m pretty sure secure boot is beyond my capabilities. I wont even try.
I really think that we can extend the acme service to have enough options to support many acme clients out there such as lego or certbot itself. We have some kind of “interface” already for the http challenge (i.e. where other services expect certs to be available on disk or the preDelay script…), we “just” need to make sure we have an interface for the DNS challenge too
I’ve been fixing some bugs in the acme client the past month, which should be merged soon.
Working with it, the interface so far is pretty tightly coupled to both simp_le and nginx I think it would be better to just start a new module with the idea of multiple challenges baked in from the get-go. I would not try to make it acme-client agnostic though; that seems to add needless complexity. we keep the old acme module and create a new lego module that supports multiple challenges and what not. Changing the old acme module to support multiple challenges and acme clients, whilst remaining backwards compatibility seems too much of a hassle to me.