numtide / flake-utils Goto Github PK

I have a flake that provides a docker image as package in its output.

All but docker image are buildable and should run on the "default systems", so I wanted to move the docker image out of the function into its own attribute set which I then merge them, though due to the way // works, one packages overwrites the other:

outputs = { … }
  {
    packages.x86_64-linux.image = …;
  } // eachDefaultSystem (system:
  {
    packages.somethingElse = …;
  }

will create a flake only provides somethingElse for the default systems, if you turn it around to be

outputs = { … }
  eachDefaultSystem (system:
  {
    packages.somethingElse = …;
  }) // {
    packages.x86_64-linux.image = …;
  }

You will end up with the x86_64-linux.image only.

a mergeOutputs could take a list of attribute sets thats then gets deepmerged, usage would be roughly:

outputs = { … }
  mergeOutputs [
    (eachDefaultSystem (system:
    {
      packages.somethingElse = …;
    }))
    ({
      packages.x86_64-linux.image = …;
    })
  ];

The need to add recurseIntoAttrs causes pollution of the attrset with the marker attribute. That prevents it from being set as the packages output of a flake.

In checks, I do wish to use flattenTree. But in packages I don't. But I must in order to remove the marker attr. And that goes for other places packages ends up in.

This makes me wish for a flattenTree that doesn't need recurseIntoAttrs.

Dime for you thoughts?

This is what I'm doing now. I know there are more sophisticated versions around that will check dependencies recursively. This seems eligible for flake-utils, any overlay or package set providers will likely want to use some sort of function like this.

(Bonus points if we discuss whether to filter unsupported platforms out entirely, or if we give a more helpful error in those cases.)

Describe the bug

nix flake update on existing flakes is broken since branch rename to main

To Reproduce

inputs.flake-utils.url = github:numtide/flake-utils/master;

$ nix flake update
error: unable to download 'https://api.github.com/repos/numtide/flake-utils/commits/master': HTTP error 422

       response body:

       {
         "message": "No commit found for SHA: master",
         "documentation_url": "https://docs.github.com/rest/commits/commits#get-a-commit"
       }
(use '--show-trace' to show detailed location information)

Expected behavior

Update functions

System information

NixOS 22.11

Additional context

This is a backwards compat issue as it breaks existing flake.nix that used master branch instead of main.

The current overlays attribute returned by simpleFlake is a list where it seems that the "canonical" (See https://nixos.org/manual/nix/unstable/command-ref/new-cli/nix3-flake-check.html and https://nixos.wiki/wiki/Flakes ) format is to have it as a mapping.
Having it as a mapping would allow to apply a subset of the overlays more easily.

It's not clear which of two below results is the correct one, as both are present in the example for eachSystem:

hello.x86_64-linux.hello = 42;

or:

hello.aarch64-linux = 42

— the important difference being that the 2nd one has no .hello at the end...?

Is your feature request related to a problem? Please describe.
I'm finally checking out Nix flakes now that Nix 2.4 is out, and there's a bunch of extra stuff to remember. flake-utils looks really handy for things like setting up a devShell flake, but there's still annoying boilerplate there.

Describe the solution you'd like
It would be really handy if flake-utils could vend some templates for use with nix flake init. In particular I would love a template for devShell specifically that wraps shell.nix. The NixOS Wiki page on Flakes suggests

{
  description = "my project description";

  inputs.flake-utils.url = "github:numtide/flake-utils";

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem
      (system:
        let pkgs = nixpkgs.legacyPackages.${system}; in
        {
          devShell = import ./shell.nix { inherit pkgs; };
        }
      );
}

So having something like this as the template (perhaps with a better description though) would be very convenient.

Is your feature request related to a problem? Please describe.

Not related to a problem.

Describe the solution you'd like

I would like to be able to use a semantic version pin of flake-utils in my project's flake.nix.

{
  description = "Example flake-utils pin";

  inputs = {
    nixpkgs.url = github:NixOS/nixpkgs/nixos-21.11;
    flake-utils.url = github:numtide/flake-utils/1.2.3;  # <-- See here
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let pkgs = nixpkgs.legacyPackages.${system}; in
      rec {
        packages = flake-utils.lib.flattenTree {
          hello = pkgs.hello;
          gitAndTools = pkgs.gitAndTools;
        };
        defaultPackage = packages.hello;
        apps.hello = flake-utils.lib.mkApp { drv = packages.hello; };
        defaultApp = apps.hello;
      }
    );
}

This would require a release cycle for flake-utils and pushing of git tags. See mach-nix for an example.

Describe alternatives you've considered

1. Not using version pinning.
2. Pinning to a git hash, inputs.flake-utils.url = github:numtide/flake-utils/12806d31a381e7cd169a6bac35590e7b36dc5fe5

Additional context

I might also be wrong and this is a stupid idea to begin with :)

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

there are many packages specify the mainProgram in meta section, the mkApp should follow that conversion and use bin/$drv.meta.mainProgram by default.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

When I put nixops under forEachSystem it stops to work. How can it be made to work?

Describe the solution you'd like

Likely nixops should be pushed up, may be something like is done with hydra so it works well.

Describe alternatives you've considered

I am trying to override input via ad hoc flake-utils in our ci to retain only x86-64_linux ops and handle nixops well.

Also trying to make nixops // flake-utils... . Problem is that nixops depends on flake-utils build.

Additional context

Currently filterPackages has this piece of code:

      platforms = meta.hydraPlatforms or meta.platforms or allSystems;

However, is checking meta.hydraPlatforms the proper thing here? Many packages use meta.hydraPlatforms = []; to mark “trivial” packages (e.g., wrappers like firefox) that are not really useful to cache on Hydra; this does not mean that the package does not build. There are other cases when meta.hydraPlatforms is empty (e.g., packages having non-free dependencies like NVidia drivers, or packages with outputs not fitting into Hydra limits). So if I want to reexport such packages from my flake, then I either cannot use filterPackages (which could otherwise be useful to avoid exporting packages that don't actually build for a particular system), or would need to patch out meta.hydraPlatform from packages (which does not seem to be right).

Describe the bug

If you specify an overlay attribute when using flake-utils.lib.eachSystem, nix flake check will fail because the final overlay attribute has invalid argument names.

To Reproduce

Steps to reproduce the behavior:

1. Create a flake with an overlay
2. Run nix flake check

My flake is roughly this:

{
  outputs = { self, nixpkgs, flake-utils, ... }@inputs:
    flake-utils.lib.eachSystem ["aarch64-linux" "x86_64-linux"] (system: {
        # ... other stuff

        overlay = final: prev: {
          foo = packages.foo;
        };
      }
    );
}

Error:

$ nix flake check --show-trace
error: overlay does not take an argument named 'final'

       … while checking the overlay 'overlay'

       at /nix/store/kfpqwqdzm3rf153hr63hp4v81xbm5bx4-source/default.nix:75:15:

           74|             {
           75|               ${key} = (attrs.${key} or { }) // (if key == "hydraJobs"
             |               ^
           76|               then builtins.mapAttrs (name: value: (attrs.hydraJobs.${name} or { }) // { ${system} = value; }) ret.hydraJobs

       … while checking flake output 'overlay'

       at /nix/store/kfpqwqdzm3rf153hr63hp4v81xbm5bx4-source/default.nix:75:15:

           74|             {
           75|               ${key} = (attrs.${key} or { }) // (if key == "hydraJobs"
             |               ^
           76|               then builtins.mapAttrs (name: value: (attrs.hydraJobs.${name} or { }) // { ${system} = value; }) ret.hydraJobs

Expected behavior

nix flake check should pass.

Additional Context

$ nix --version
nix (Nix) 2.5pre20211007_844dd90

Describe the bug

flattenTree cannot seem to flatten legacyPackages to a packages-compatible format; the resulting attribute set is empty.

To Reproduce

Steps to reproduce the behavior:

legacyPackages = import nixpkgs {};
# packages = flattenTree legacyPackages;
# packages = flattenTree (mapAttrs (n: v: legacyPackages.${n}) legacyPackages);
# packages = flattenTree (genAttrs (attrNames legacyPackages) (pkg: legacyPackages.${pkg}));
packages = flattenTree { hello = legacyPackages.hello; };

The commented packages assignments all fail, while the last one succeeds, verified by trace packages.

Expected behavior

I thought the commented assignments result in the same attribute sets as the last assignment.

System information

NixOS 22.05, using nix (Nix) 2.5.0pre20211206_d1aaa7e and the master branch flake-utils.

Additional context

Here is the actual config, as opposed to the minimal example above.

now that NixOS/nixpkgs#167947 has been merged there is now a lib/flakes.nix

assigning myself

Using simpleFlake, assuming nix build .#release is meant to build a release from source code:

It would be nice to provide access to the flake's self somehow to do src = self when needed.
A global reference to repo root seems somehow a little more flakeonic, than doing src = ../../. (or whatever relpath).

Not sure if possible, though, without altering the signature of the overlay.nix file.

Would also alleviate enforcement of proposal in #15, I guess.

Is it really a problem to break compat with nix-*? For those who need it it could be overlay.nix + overlay.fl.nix (a thin wrapper that does what it can).

Describe the bug

To Reproduce

Steps to reproduce the behavior:

1. use nix run on a repo with the an app made with flake-utils.lib.mkApp
2. errors with error: attribute 'defaultApp.x86_64-linux' should have type 'derivation'

Expected behavior
the app executes normally

System information
nix 2.8.0 linux

Additional context
nix 2.8.0 has more strictness the nix 2.7 which has broken flake-utils

Describe the bug

see: https://discourse.nixos.org/t/relative-path-support-for-nix-flakes/18795
and: NixOS/nix#3978 (comment)

I am basically doing this already here, but I wonder if there is a better way to do it that could be generalized so we could call it on a flakes packages output.

Essentially I am checking if a derivation has a bin directory in its outpath, and if so, calling mkApp on it. This requires building the derivation, which will fail on other systems, so I perform the check only on the version of the package for the currently running system.

Hopefully this can be simplified and omptimized.

Hi, is there any way to include a nixos module with simple flake? I can't seem to work this out

I wonder if this is a good enough abstraction to be encourage by this repo:
https://github.com/nix-community/flake-nimble/blob/22e4e490b5d5ad15e78c9225022d0dc43d65af8a/flake.nix#L55-L64

See also: https://discourse.nixos.org/t/getting-started-nix-repository-template/8024/17?u=blaggacao

# pseudo
{
    devShell = flake-utils.lib.mkShell { buildInputs = [ ". . ." ]; };
}

Unless I'm mistaken, the preferred solution for generalizing across system architectures with Nix flakes is flake-parts by the Hercules CI team; reason being, you can separate attributes that are truly hermetic from those that depend on a particular system with flake-parts, but not with flake-utils.

Conjecturally, we might either put flake-parts in the nix-community organization or even integrate it into the Nix mainline once flakes themselves are stable. In either case, there should be no reason to maintain this repo other than for compatibility.

cc @srid @roberth

Hello!

How would I go about using this as a replacement for my configuration.nix file, if at all possible? I would like to make sure my config is as pure as possible; here is my current attempt at integrating flake-utils with my flake.nix:

{
  description = "shadowrylander";

  inputs = rec {
    home-manager = {
      url = "github:nix-community/home-manager/master";
      # https://github.com/nix-community/home-manager/blob/master/flake.nix#L4
      # HM takes 'nixpkgs' as input
      inputs.nixpkgs.follows = "nixpkgs";
    };
    mach-nix = {
        url = "github:davhau/mach-nix/master";
        # url = "/etc/nixos/extras/mach-nix";
        inputs.nixpkgs.follows = "nixpkgs";
    };
    # impermanence = {
    #   url = "github:nix-community/impermanence";
    #   flake = false;
    # };
    flake-utils = {
        url = "github:numtide/flake-utils";
        inputs.nixpkgs.follows = "nixpkgs";
    };

    t3.url = "github:NixOS/nixpkgs/nixos-20.03";
    t9.url = "github:NixOS/nixpkgs/nixos-20.09";
    unstable.url = "github:NixOS/nixpkgs/nixos-unstable";
    small.url = "github:NixOS/nixpkgs/nixos-unstable-small";
    master.url = "github:NixOS/nixpkgs/master";

    nixpkgs.follows = "master";

    nix = { url = "github:NixOS/nix/master"; };

  };

  outputs = inputs@{ self, nixpkgs, flake-utils, ... }:
    with flake-utils.lib; eachSystem allSystems (system: let
      pkgs = (import nixpkgs {}).legacyPackages.${system};
    in rec {
      packages = flake-utils.lib.flattenTree {
        nixosConfigurations = let
          base = {
            global = {
              modules = with inputs; [
                home-manager.nixosModules.home-manager
                # mach-nix
              ];
            };
          };
          systems = let stdenvs = (import ./shared/global/stdenvs.nix { inherit pkgs nixpkgs; }); in {
            imd = let _imd = stdenvs.imd; in {
              x64 = _imd.x64.system;
              x86 = _imd.x86.system;
            };
            arm = let _arm = stdenvs.arm; in {
              x64 = _arm.x64.system;
              x86 = _arm.x86.system;
            };
          };
          create = { hostname, pkgs ? pkgs }: let
          # create = { hostname, system ? systems.imd.x64 }: let
          # create = { hostname, system ? systems.imd.x64, pkgs ? pkgs }: let
            config = ./. + "/configs/${hostname}.nix";
          in pkgs.lib.nixosSystem {
            inherit system pkgs;
            modules = base.global.modules ++ [ (import config) ];
          };
        in {
          siluam = create { hostname = "siluam"; };
        };
      };
      defaultPackage = packages.nixosConfigurations;
      apps.nixosConfigurations = flake-utils.lib.mkApp { drv = packages.nixosConfigurations; };
      defaultApp = apps.nixosConfigurations;
    }
  );
}

Thank you kindly for the help!

Hey I'm not here to really gripe about anything missing, but more to highlight how recent changes to the flake spec in Nix 2.7.0 make eachSystemMap a really elegant function.

If you agree I I'll PR some README updates to highlight the new patterns, since I think it'd be good to put it front and center.

For context Nix 2.7.0 deprecates defaultXXX.${system} in favor of packages.${system}.default making it easier to wrangle defining defaults.
This snippet below is for a trivial project I have with a standard package installation. This flake makes it available to nix-command, or it can be consumed in NixOS/home-manager as a module, or in legacy nix + nixpkgs projects as an overlay.

The boilerplate required previously to handle the defautXXX outputs used to be real ugly.

{
  description = "A handful of useful core utilities and scripts for Linux";

  inputs = {
    nixpkgs.url = github:NixOS/nixpkgs/nixpkgs-unstable;
    utils.url   = github:numtide/flake-utils;
  };

  outputs = { self, nixpkgs, utils }:
    let
      eachDefaultSystemMap = utils.lib.eachSystemMap utils.lib.defaultSystems;
    in {
      packages = eachDefaultSystemMap ( system: rec {
        ak-core =
          ( import nixpkgs { inherit system; } ).callPackage ./default.nix {};
        default = ak-core;
      } );

      overlays.ak-core = final: prev: {
        inherit (self.packages.${final.system}) ak-core;
      };
      overlays.default = self.overlays.ak-core;

      nixosModules.ak-core = { ... }: {
        nixpkgs.overlays = self.overlays.ak-core;
      };
      nixosModule = self.nixosModules.ak-core;
    };
}

I can faintly see why package overlays are namespaced, even though simple flake does not reexport them in output.overlay.

Is it enough to encourage this as a convention vs enforcing it in the flake spec?

Hi,

I'm currently building a flake which, in its checks, uses valgrind as a build input. This fails due to the fact that valgrind is marked as broken in darwin (due to being unavailable since Catalina). Is there a way to explicitly remove a particular derivation from a particular system?

To better explain, this is the relevant part of my nix flake show output:

├───checks
│   ├───aarch64-linux
│   │   ├───build-check: derivation 'energy-storms-all'
│   │   ├───correctness-check: derivation 'energy-storms-correctness-check'
│   │   ├───profiling-check: derivation 'energy-storms-profiling-check'
│   │   └───valgrind-check: derivation 'energy-storms-valgrind-check'
│   ├───i686-linux
│   │   ├───build-check: derivation 'energy-storms-all'
│   │   ├───correctness-check: derivation 'energy-storms-correctness-check'
│   │   ├───profiling-check: derivation 'energy-storms-profiling-check'
│   │   └───valgrind-check: derivation 'energy-storms-valgrind-check'
│   ├───x86_64-darwin
│   │   ├───build-check: derivation 'energy-storms-all'
│   │   ├───correctness-check: derivation 'energy-storms-correctness-check'
│   │   ├───profiling-check: derivation 'energy-storms-profiling-check'
│   │   └───valgrind-check: derivation 'energy-storms-valgrind-check'
│   └───x86_64-linux
│       ├───build-check: derivation 'energy-storms-all'
│       ├───correctness-check: derivation 'energy-storms-correctness-check'
│       ├───profiling-check: derivation 'energy-storms-profiling-check'
│       └───valgrind-check: derivation 'energy-storms-valgrind-check'

I would like for the x86_64-darwin system to simply not have the valgrind-check. I have looked at filterPackages but, due to the lack of documentation on this function and the lack of examples of configurations using this function, I was unable to figure out how it works and if it would suit this purpose.

i am doing nix flake check and get

error: error: a 'aarch64-darwin' with features {} is required to build '/nix/store/22zx8fsi94pa9p9m3w1m21ylb7fb55xa-yarn.nix.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

may we have flake doing only linux x86 override to flake so that we can smoke test whole nix in ci.

without having arm test.

When you want to reference a package from another package, or a devShell, etc... inside eachSystem/eachDefaultSystem closure then you have to either use the pesky rec keyword which even does not work for all cases or you have to use self parameter from the flake itself like self.${system}.packages.abc which is unnecessarily repeating the system.

I propose adding a variant of eachSystem/eachDefaultSystem which could be used like this:

{
  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem2 (sself: system: {
      packages.abc = ...;

      devShells.default = pkgs.mkShell {
        packages = [
          sself.packages.abc # Instead of self.${system}.packages.abc;
        ];
      };
    });
}

Perhaps it could be made backward compatible similar to overrideAttrs (NixOS/nixpkgs#119942) so new variant of eachSystem may not be necessary.

When I run the eachDefaultSystem example with nix develop I get:

error: flake 'git+file:///...' does not provide attribute 'devShells.x86_64-linux.devShell.x86_64-linux', 'packages.x86_64-linux.devShell.x86_64-linux', 'legacyPackages.x86_64-linux.devShell.x86_64-linux', 'devShell.x86_64-linux' or 'defaultPackage.x86_64-linux'

I am using nix through home manager on opensuse Tumbleweed

Wouldn't it make the public api of a simple flake repo cleaner if default*, eg defaultPackage would not be re-exposed in packages?

So that we would do:

# ./overlay.nix
final: prev:
{
  simple-flake = {
    hello = prev.hello;
  };
  defaultPackage = prev.hello;
  devShell = {};
}

Is your feature request related to a problem? Please describe.

I'd like to be able to only depend on semver tagged releases for my flake inputs.

Describe the solution you'd like

The last release was in May 21, 2022. Currently, this project seems to be at the end of it's development lifecycle. There are a few changes per month it seems. Perhaps a monthly semver tagged release (when there is changes) would be appropriate for flake-utils?

Describe alternatives you've considered

Another option might be to cut a release on each commit, but having an amount of time where it's live but not releases would allow potential bugs to emerge.

Additional context

Would this flake-utils be a good home for a by-name function for the community? A by-name function that provides callPackaging from */package.nix, similar to what was recently added to Nixpkgs.

How hard would it be to generate a cross compiler toolchain to allow users to cross compile to targets? For example, this would let me build defaultPackage.x86_64-darwin on linux. Or really any of the generated targets.. Doesn't seem like this is how things work right now. I see a bunch of targets generated, but I get errors when trying to cross compile to them. Would probably just be a nixpkgs override with cross system to generate different package sets for each target based on the host system. What do you guys think of this?

Is your feature request related to a problem? Please describe.

The instructions for using simpleFlake do not work on OSX. I followed the instructions in the README and used the example project.

This is due to the default value for systems to be [ "x86_64-linux" ]. In order to get it working I added a single line to set the systems attribute in my flake.nix to point to defaultSystems instead.

It would be good if OSX was supported out the box.

Describe the solution you'd like

Change the code to have this value be defaulted to defaultSystems.

Describe alternatives you've considered

Update the README to include an OSX friendly example

{
  description = "osx-example";

  inputs.flake-utils.url = "github:numtide/flake-utils";

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.simpleFlake {
      inherit self nixpkgs;
      name = "osx-example";
      systems = flake-utils.lib.defaultSystems;
      overlay = ./nix/overlay.nix;
      shell = ./nix/shell.nix;
    };
}

I just ran into an odd issue with eachDefaultSystem.

In the below flake, the dockerImage = pkgs.dockerTools.buildImage output does not work correctly.

Running nix-build .#dockerImage produces the error error: flake output attribute 'dockerImage' is not a derivation.

The same command works fine if I remove eachDefaultSystem and specify the system manually.
It appears the mapping somehow messes up the final output.

{
  description = "dynastic - Static Site Server";

  inputs = {
    nixpkgs.url = github:NixOS/nixpkgs/nixos-unstable;
    flakeutils.url = "github:numtide/flake-utils";
    naersk.url = "github:nmattia/naersk";
  };

  outputs = { self, nixpkgs, flakeutils, naersk }: 
    flakeutils.lib.eachDefaultSystem (system:
      let
        system = "x86_64-linux";
        pkgs = nixpkgs.legacyPackages."${system}";
        naersk-lib = naersk.lib."${system}";
      in rec {

        packages.dynastic = naersk-lib.buildPackage {
          pname = "dynastic";
          src = self;
          root = ./.;

          buildInputs = with pkgs; [
            pkgconfig
          ];
          propagatedBuildInputs = with pkgs; [
            openssl
            libgit2
          ];
          runtimeDependencies = with pkgs; [
            openssl
            libgit2
          ];
        };

        defaultPackage = packages.dynastic;

        apps.dynastic = flakeutils.lib.mkApp {
          drv = packages.dynastic;
        };
        defaultApp = apps.dynastic;

        devShell = pkgs.stdenv.mkDerivation {
            name = "dynastic";
            src = self;
            buildInputs = with pkgs; [
              pkgconfig
            ];
            propagatedBuildInputs = with pkgs; [
              openssl
              libgit2
            ];
            buildPhase = "";
            installPhase = "";

            RUST_BACKTRACE = "1";
            RUSTFLAGS="-C link-arg=-fuse-ld=lld";
            LD_LIBRARY_PATH="${pkgs.libgit2}/lib:${pkgs.openssl.out}/lib:${pkgs.sqlite.out}/lib";
        };

        dockerImage = pkgs.dockerTools.buildImage {
          name = "theduke/dynastic:0.0.1";
          config = {
            Cmd = [ "${packages.dynastic}/bin/dynastic" ];
          };
        };
      }
    );
}  

It might become mainstream (and actually be intended UX) to run CI/precommit checks with nix checks .#... and tests with nix run .#... as seen in: https://github.com/input-output-hk/haskell.nix/pull/972/files#diff-831cd2fba465f6aa9b5ef7e0dd8f890afafb79eef581915b6de1e01c587f12f2R619-R641

Hence it might be worthwhile to expose checks and apps transparently through the simpleFlakes overlay pattern?

/cc @hamishmack

As an alternative to flattenTreeSystem, I propose filterSystem that directly acts on the output of current flattenTree and filters with a predicate that drops all packages that would trivially fail a nix flake check.

/cc @Pacman99 @nrdxp

Is your feature request related to a problem? Please describe.

Not related to a problem.

Describe the solution you'd like

I would like to be able to use a semantic version pin of flake-utils in my project's flake.nix.

{
  description = "Example flake-utils pin";

  inputs = {
    nixpkgs.url = github:NixOS/nixpkgs/nixos-21.11;
    flake-utils.url = github:numtide/flake-utils/1.2.3;  # <-- See here
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let pkgs = nixpkgs.legacyPackages.${system}; in
      rec {
        packages = flake-utils.lib.flattenTree {
          hello = pkgs.hello;
          gitAndTools = pkgs.gitAndTools;
        };
        defaultPackage = packages.hello;
        apps.hello = flake-utils.lib.mkApp { drv = packages.hello; };
        defaultApp = apps.hello;
      }
    );
}

This would require a release cycle for flake-utils and pushing of git tags. See mach-nix for an example.

Describe alternatives you've considered

1. Not using version pinning.
2. Pinning to a git hash, inputs.flake-utils.url = github:numtide/flake-utils/12806d31a381e7cd169a6bac35590e7b36dc5fe5

Additional context

I might also be wrong and this is a stupid idea to begin with :)

I'm very unconvinced about using a flake import to override the systems that "eachDefaultSystem" is going to build for. I love flakes but seeing inputs used for this seems confusing to me.

Further, I've been looking at/for examples, etc, and have no idea how to get jj (https://github.com/martinvonz/jj) to support riscv64-linux.

Is your feature request related to a problem? Please describe.
It's more difficult to discover projects like this if they're scattered around multiple organizations. nixos and nix-community are ones people will usually be aware of. Unless nixpkgs gets something like this out of the box (and I don't know if this might be coming at all) it would be nice to have this repository in a more discoverable location.

Describe the solution you'd like
Moving this repository to nix-community

Describe alternatives you've considered
Not doing it, and just referring to numtide/flake-utils