Hi here,
It is just me, or it seems the project is in “standby” state. I am not sure if the right term, but I don’t want to say that the project is dead for the moment. The forum doesn’t have really activity since weeks.
Anybody could do a status about the Auxolotl project ?
Hey! While the project isn’t dead, it is slow moving. Everything here depends on people contributing to build the things in our roadmap. For the most part the group that has been working on stuff has been quite small. I still intend to continue working on Aux projects when time and energy allows, but don’t expect a huge amount of velocity from that 
Thank you for your reply.
What can people help with?
I stumbled into this recently. What are the goals with lib, foundation and tidepool? How can we help?
Hey @samrose!
Here is the current lay of the land:
The goal here is to have an isolated reimplementation of the many pure-nix helpers that Nixpkgs has. This is currently fully functional and is used in Foundation, Tidepool, and even by some community members’ projects. We can add additional things here if necessary, but ideally we keep it as limited/focused as possible.
TL;DR:
Not much work needed here!
To build a package set we needed to have some packages already. Thankfully the folks working on Guix had built out a great i686 bootstrap chain and Emily Trau ported/built much of the same for Nixpkgs. The Nixpkgs work wasn’t done last I checked, but I got some help from Emily when I was working on Foundation to get the whole bootstrap working. In the future it would be great to have working bootstrap chains for different architectures, but some upstream blockers prevented that. This is okay since we can build cross compilers with our existing outputs.
TL;DR:
No work needed here!
This is the big one. With bootstrapped packages we can start to build a larger package set. I initially built out a purely module-based solution for handling all packages and other outputs. @VlinkZ did some excellent work getting cross compilation from i686 to x86_64 working which gives us a solid point to begin adding more packages from. However, we found that eval time was growing rapidly due to the number of submodules being cloned and evaluated. We still think modules are useful, but a more restrained solution seems necessary here. I want to switch from pure module system to using fixed points for package sets while still allowing package configuration/declaration/modification using modules.
TL;DR:
This is where we need to do the work. Package modules will still be used for definition and override, but we want to pass around derivations in fixed points instead of the current structure. After that, adding more packages!
If you want to dive in I would recommend looking at the Tidepool code and trying to build one of the packages. You’ll see the whole bootstrap chain and how we get to the package set. You will probably also observe some of the eval slowdown caused by Tidepool’s current structure. After giving that a try, feel free to experiment a bit! Our goal here is to make something easy to use, for both the maintainer and consumer of these projects. If you have some ideas then please feel free to try! Also let us know either here on the forum or on the Matrix instance!
If i understand correctly then i could try to package some software in Tidepool ?
Not quite yet unless they are core compiler/library pieces. We need to rework the package set structure to avoid extra evals. After that then we should be in a good place to add more packages.
If anyone wants to help right now the thing to do would be to clone Tidepool and shift things around to be a fixed-point with package modules still being used for the individual definitions.
Well i will take a look and try see what poking it does 