I’m a college student and moderately-experienced Nixpkgs contributor looking at possible doing Google’s Summer of Code this summer, and I’d love to work on something Nix-related. It looks like Nix didn’t get registered as a mentor organization this year, but the Linux Foundation seems willing to mentor on behalf of organizations that missed the deadline, so I figured I’d bring this up and ask if there’s interest.
Below are some various ideas I’ve been interested in working on. I’m also very open to ideas not listed here!
Improving the NixOS installation/new-user experience
Putting together a graphical installer, maybe based on Calamares?
Getting nixpart up and running and merged into nixpkgs?
Building a way to programmatically read and modify NixOS configuration, for use by an installer or GUI configuration tools?
Improving language packaging
Building Node.js packages from source instead of downloading pre-compiled packages from NPM?
Using nix-ccache in nixpkgs (this depends on Recursive Nix; not sure if that’s stable enough to start building on top of)?
Gathering and centrally collecting statistics from Nix builds (time? memory usage? disk usage?) to provide better time estimates and warning if there are insufficient resources for a build?
Running nix-packaged software on AWS Lambda (where, AIUI, we don’t have root and therefore we’d need some sort of chroot or container to write to /nix), and using Lambda as an infinitely-scalable remote builder?
I’d also love to hear from any other GSoC mentoring organizations interested in Nix-related work (or, for that matter, any companies using Nix looking for a summer intern).
@Gaelan For your last point, nix on Lambda, there a minimal PoC here:
The initial impetus was to use this with Stanford’s gg. It’s all ugly and a massive hack and is probably out of date by now, but it may help you in some way.
Hey, I’m no mentor, but I just want to say that your alternative toolchain ideas sound really interesting. If you do decide to take that route, feel free to ping me – I’d be happy to review PRs and help out where I can.
I encourage you to contribute to nix, it would be awesome!
Around nix and nodejs, there was recently a discussion about how the how current nodejs packages doesn’t scale and is broken.
There was a discussion here https://github.com/NixOS/nixpkgs/pull/113294
The need for a new solution was mentioned but no proper direction got put forward. I would personally say there is a big need for this. The current state of things is that it’s basically very hard to contribute any nodejs package.
I would be willing to review PRs and get the right people involved, I’m nowhere near the level of being able to provide mentorship though.
Since it’s Google, it might be a fitting cabdidate to revamp k8s support from a nix perspective. Projects like GitHub - xtruder/kubenix: Replaced by https://github.com/hall/kubenix lay a good foundation. That would also play well the other way round, e.g. a kustomize plugin to render from nix-lang / kubenix config.
I have another suggestion for you which is in my opinion a bit more urgent than trying new things:
The way we package nodePackages needs a rework. The giant nodePackages file is not reviewable and node2nix stack overflows with some bigger packages like zigbee2mqtt (see zigbee2mqtt: 1.16.2 -> 1.18.1 by mweinelt · Pull Request #114896 · NixOS/nixpkgs · GitHub). I think it would be a good idea to fix those issues before we build node packages from source.
There lock files are also not tiny (https://github.com/pnpm/pnpm/blob/53324fb37262045d8b13d1ad282b71f0787609e9/pnpm-lock.yaml) and because most repos don’t have pnpm lock files we would need to create them for basically all packages. On the other hand they take care of a lot of things for us already like dependency resolution and strict dependency which we definitely want.
I think this solution will not be perfect but it could be far better than the current node2nix approach and someone else already did quite a few tasks for us and hopefully maintains them. This could potentially solve stack overflows like mq2tt currently has, simplify nodePackages and remove quite a lot of boiler code.
I am personally would be very interested in this project and if you (or someone else) wants to do it I would be open for questions and would like to share my (limited) knowledge about nixpkgs. Just mention me on IRC or write me a private message. Also if someone got a prototype working and wants to test it for nodePackages but lacks the hardware or bandwidth just create a draft PR or send me a link to a git repo with a short message and I should be able to build it within a few hours with the remote builders I have access to.
Just to make sure I understand correctly.
The idea would be to install a package with pnpm then recusively convert the symlinks to the packages to the nix store.
The way to start would be to take a package with no dependency and try to convert the pnpm format to nix. Maybe something like function-bind (https://www.npmjs.com/package/function-bind) (I just did a quick search, anything would work). The second step would be to figure out the recursive part.
Just making sure I understand the concept. Feel free to correct me.
Yeah I think it’s crucially important than our language and language-specific package manager support be better, but until we find something like IFD to make using those in Nixpkgs productive, I think it’s a bit premature to have a GSOC on them :/. Right now the sad truth is Nixpkgs is our best community effort but the best-designed language-specific stuff proposers despite and not because that community energy :(.