A basic template

The idea I wish to present is a flake(?) template that allows users to quickly get into aux and get started using aux as fast as possible. Ideally this world be broken into maybe 3 or 4 templates including just aux packages, one with home-manager, a darwin example and a simple packaging example.

I feel this would be best few basic templates to help get users up and going as fast as possible.

cc @coded @minion


100%, let’s do this. It’s relatively easy to get flake templates which can be used with the -t flag on the new CLI, @coded shall we hop on a call and get started?

We can work on this immediately and put it into the GitHub org when we’re in there


Sounds good to me. For anyone else who’d like to join let’s meet in Jitsi Meet

Quick question, wouldn’t the templates just be a standard flake template but with the nixpkgs.url pointing to our nixpkgs? Just making sure I’m following along correctly.

(also it’s like 1am here, so most of my braincells are gone atm :smile:)

So at first I thought like you but when I did more digging into the nix templates repo, they don’t have any proper system configurations which was shocking. Hopefully this should rectify that.

Pretty much indeed, for now.
Here is a small flake providing GNU Hello

  inputs = {
    auxpkgs.url = "github:auxolotl/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";

  outputs = {
    flake-utils.lib.eachSystem [
    ] (system: let
      pkgs = auxpkgs.legacyPackages.${system};
    in {
      formatter = pkgs.alejandra;
      devShells.default = pkgs.mkShell {
        packages = [pkgs.hello];

(both as a devShell and using nix run .#hello)

1 Like

My first goal is to kill remove flake-utils, it is almost never needed.


I know about Viper’s blog, but still use it in all my flakes because I think it is fine :sweat_smile:

1 Like

It depends on complexity. There are definitely reasons why some level of abstraction may be necessary. Hence things like Snowfall Lib:

1 Like

Snowfall is excellent, I wonder if we should make it one of our templates too


Happy to announce our templates are live


sweet :tada:

Would it be worth adding how to merge home-manager on top of the existing nix-darwin or system template (and/or vice versa)? When starting out to manage a computer + my homefiles this step will eventually come up.

Small nitpik/ suggestion: Rename the system template to something more descriptive that does not overlap in meaning with the system attribute.
Linux comes to mind but it feels to ambigious. But than the range of supported systems can also be some more wider…

Damn it’s getting late, can’t think of a proper name right now. In case this comment doesnt speak to you, plz disgard it.


Should we move this from documentation to core? This doesn’t seem like a documentation issue to me, and people might get confused what it is

When we were working on the templates earlier, we were using auxports instead of nixpkgs right?

Why do the templates say nixpkgs now? :smiley:

Let’s keep it as nixpkgs for now if it is referring to our nixpkgs fork. Otherwise if we are pointing to our “packages” repository we can reference that as “Aux Packages” for now:


Ah! Okay!
I missed this. :+1:

1 Like

I think the original idea of having it in docs is that it’s about onboarding new members & getting a system up and running, but I agree that in isn’t the sort of thing you immediately think of as docs. I have no great objections to core taking over so long as they want it, believe they can maintain it, and the rest of the docs team doesn’t speedily raise some objections I hadn’t thought about


IMO it makes more sense for the folks closer to the technology to own the onboarding process. We can always reference it in docs and quick-start guides no matter where it lives.

Sounds good, @isabel is core happy to take the repo?

I’m certainly happy to take it. But I think that it would be a good idea to share the templates repo between core and docs. Especially since this is the first place users are going to see aux, so I think its a good idea that the docs team were on top of any changes that were to come in and ensure that the information we put there is accurate and easy to understand.