following The Future of NixCPP: Lix and the amount of support for adopting it over our cppnix fork, i think now may be a good time to reflect on some of the other forks originally laid out in the roadmap. namely, nixpkgs
now, this is a major part of our roadmap. just like our cppnix fork, it is actually in the first sentence
We will fork and maintain Nix, NixPkgs, and NixOS.
i can understand the hesistancy around any changes here, but following the discussions in the thread mentioned above, i have hope that we can have a good discussion here as well and find a way to give a better experience to users, while also lessening the burden on contributors
Our current state of affairs
as of now, our nixpkgs fork isnāt in the best shape. for the most part, we are always lagging behind upstream and simply pulling in there changes every hour. with the exception of ~4 PRs, we havenāt made any real changes. maintaining this creates a few issues
Unclear instability and security risk for our early users
judging by some posts iāve seen here and communications iāve had elsewhere, a lot of the recent drama has actually introduced new people to both nix and aux, and these people are of course looking for a way to start using one or the other. there are also many pre-existing users who are looking to move to an alternative better aligned with their values. if either of these groups choose aux, they will be using our nixpkgs fork ā which as stated before, doesnāt provide the best experience right now
the biggest issue here is that only master is synced. if an existing user simply does a s/nixos/auxolotl/
on their nixpkgs input and are using anything besides master (which will be basically everyone), they are getting an out of date and possibly insecure version of nixpkgs. this is currently not made clear anywhere
for new users, they will most likely use github:auxolotl/nixpkgs
. this inherits many of the issues of nixpkgs master such as less binaries and less testing, and is then compounded by any changes we make (that also arenāt currently being tested). once again, this is also not really stated anywhere, and new users are unlikely to understand the differences between master, nixos-unstable, and nixos-23.11/24.05
if anything is to come out of this post, this must be resolved. we should be actively discouraging the use of this until then, especially as there is no real advantage to using this fork as of now. bad experiences using this fork like this can easily result in driving new users away from both aux and nix
A weird relationship with upstream
as said before, we regularly sync with upstream nixpkgs while also accepting some contributors. this creates a few problems, such as needing to worry about our changes possibly making the binary cache unusable. more important long term though, it creates an odd situation for contributors
for this example, lets say i want to add a new package called auxcord
(like in your car, not discord). i can take a few paths here
- contribute directly to auxās fork: i use aux, so my first instinct would be to contribute to the aux repository iām using. all aux users benefit!
- contribute directly to nixpkgs: i use aux, but i also know many donāt. i also might have other packages already in nixpkgsā¦so what if i contribute there instead? in this case not just aux benefits, but also the rest of the community!
as someone who does maintain some packages and plans on adding more, the obvious choice seems to be the latter. after all i want my packages benefitting as many people as possible, and aux will be pulling the change from nixpkgs anyways. what reason would i have to contribute to aux?
now trying to put myself in the shoes of someone who only uses aux, i still canāt really find a reason to contribute to the fork. at the very least, contributing to nixpkgs directly instead will (mostly, assuming no changes to dependencies in aux or other situations) guarantee i will have my contribution cached. the only reason iāve thought of is one out of principal in the case you disagree with the foundationā¦but as we are still pulling in their changes regularly, i would argue this stance doesnāt really do much at current time
some other important points to note here is how easily this can lead to literally line-for-line duplicated effort (this has already happened. see factorio: 1.1.104 -> 1.1.107 by Daholli Ā· Pull Request #2 Ā· auxolotl/nixpkgs Ā· GitHub and factorio: 1.1.104 -> 1.1.107 by WooDyDooKs Ā· Pull Request #305320 Ā· NixOS/nixpkgs Ā· GitHub) and a situation where the aux project is directly taking without giving anything back (this is also happening and will continue to with PRs made to the fork directly). as a contributor to nixpkgs, this isnāt the best feeling ā even if i do align myself much more with auxās values
A huge burden on us
following discussion in Musings on a monorepo versus developer oriented distribution, SIG Repos: How should they work?, and some PR threads, the decision has been made (and work has begun) on splitting the monorepo structure of nixpkgs into individual repositories, each with a narrow focus. as some of you may already know, i am a huge supporter of this and i think one of the best technical ideas weāve had here, and as such i think it should be our focus
regardless of my feelings on this subject though, we have a clear issue: we are splitting maintenance between both all of nixpkgs, and individual repositories.
nixpkgs alone is a massive undertaking for even the current upstream contributor base. adding onto this with repositories meant to eventually replace it is something i donāt think any project could properly handle ā at least not without sacrifices being made on both ends, resulting in a worse final product
A solution?
i propose we drop our nixpkgs fork
given the risks associated with using it currently, the little reason for anyone to directly contribute, the long term maintenance burden, and the thin spreading of our little resources i do not think maintaining all of these is a viable goal. we should instead focus solely on our individual repository structure.
this would of course involve moving some of nixpkgs into these repositories, but it seems this is already happening. i believe this would also be much more beneficial in the long term maintenance wise and give us more opportunities to fix issues we may have with nixpkgs ā rather than go back and attempt to make these change
Some issues
the biggest one here is that this will stall the process of users actually getting aux in their hands, as without nixpkgs we would need to wait on PRs like the stdenv one linked above to be merged. iād argue this doesnāt make a big difference, though
as said before, we arenāt really making changes to nixpkgs right now. for all intents and purposes, auxās nixpkgs fork and upstream nixpkgs are the exact same, except in name. given this and the previous risks mentioned, is anyone really getting anything out of aux currently? can we even really consider or fork a fork and not just a set of string changes? i think @isabel summed this up well in a conversation we had last night
tbh we donāt even make changes to nixpkgs fork [so] why does it even exist
itās also important to note that moving efforts from the nixpkgs fork would also directly give us more resources in making the development of our individual repositories faster
A plan of action
if this proposal were to be accepted, i think we should continue as follows:
- complete and merge add stdenv by vlinkz Ā· Pull Request #2 Ā· auxolotl/core Ā· GitHub. this will allow us to work independently of nixpkgs itself, just at a smaller scale for the time being
- decide on exactly what will be considered ācoreā and add that to
core
. some prior art can be referenced here, such as arch linuxāscore
repository section and packages required by the nixos minimal iso. i prefer the latter, as it is a more tangible deliverable and would help us in tracking when this initial work in core is complete for the time being - mark core (and thus top-level) as usable, but alpha/beta. we should also be able to build a minimal āauxOSā install iso at this point, and we could release that alongside this announcement. i think this is a good way to not keep aux out of the hands of people for too long, while also giving them a product that isnāt just nixpkgs without any real changes. this is partially inspired by Lixās approach to their beta announcement, as they have already provided a distinct product for people to try
- with the foundation in core built, we should now be able to flesh language specific/broader SIG repositories. assuming the model described in SIG Repos: How should they work? - #15 by VlinkZ and flake: use core over top-level by getchoo Ā· Pull Request #1 Ā· auxolotl/javascript Ā· GitHub, repositories like python and javscript can now be built up. the intention here shouldnāt be to reach full parity with python/node/etcPackages, but be enough to lay the grounds for repositories that rely on them. a good benchmark of the work here being complete would be dependencies for gnome and kde plasma being satisfied
- with our language specific repositories fleshed out, we should now be able to move onto more narrow, but complex SIG repositories (i.e., plasma and gnome) as well as top-level. SIGs that have already completely their initial work could be much more rapid in their expansion ā as long as it doesnāt affect the newly growing repositories ā and we should get more testers involved to avoid any unforeseen issues. a good benchmark of completion here would be plasma and gnome isos being able to be built
- now that we have core, language-specific, and even DE SIG repositories at a good enough stage, we should be able to build a full install iso. i believe this would be a good mark for a beta or even initial full release
Summary
by dropping our fork of nixpkgs itself and instead moving some of it into our individual repositories, i believe we can not only help guarantee the long term viability of our maintenance load, but also give people a true ethical and technical alternative to the existing nix ecosystem. we really have something here with this concept, and i would love to see it to fruition without worrying about the tech debt of one of, if not the largest monorepos in the world layered on top