Flakes divorced from git project

Help
1

Hi all,

I’m new here but I have been using NixOS for a while and I have some understanding of the concepts.

I would like to build a project hosted on github to experiment with it and use flake tooling around it; the project currently has no flake tooling. The project has its own trajectory and someone else has already made a PR to add flake tooling but it has been rejected by the maintainers as something else they would need to maintain. I was wondering if there is a standard solution for having a flake which is not in a project’s primary git repo but could be used by anyone who wants to use a flake with a project - obviously, it would be better to have the flake in the project’s git repo but in cases where that is not possible, what is the best approach? Is this one of the use cases of flakehub?

Thanks, rgds,
Sean.

2

I mean, you could just create another repo and:

# flake.nix
{
  inputs = {
    non-flake-repo = {
      url = "anything";
      flake = false;
    };
  };

  outputs = { non-flake-repo, ... }: let
    non-flake = {
      # Exact details depend on the contents of that repo
      packages = import "${non-flake-repo}/packages.nix";
      module = import "${non-flake-repo}/module.nix";
    };
  in {
    # Use the non-flake variable as you see fit
  };
}

No need to make a separate repo for this, really, that would just complicate updates.

1 Like
3

Thanks for this @TLATER.

I guess I was not v clear in my initial post; the git repo I’m looking at knows nothing about nix and the maintainers don’t want to introduce nix at all. So it’s not a case of adding flake support to a repo which already is nix aware - the q is more around are there best practices/standard approaches for creating flakes for git repos which don’t want to (currently) add any nix support.

Thanks, rgds,
Sean.

4

They gave you the same answer I would - creating an out-of-repo flake that references/consumes the upstream repo directly is the viable pattern here. I’ve done this for years at workplaces that were Nix-agnostic and it works quite well, including when pairing it with nix-direnv. It doesn’t need a fork and perpetual rebasing, or anything more cumbersome like that. It also doesn’t matter if upstream doesn’t contain and won’t accept Nix content - you just author those in your side repo and only treat upstream as the src of the derivations you want to create.

1 Like
5

Thanks for that @shanesveller - v helpful inputs there; much appreciated.

6

In case someone else is also asking this q and ends up here, I’ll also note this which I just came across:

which seems to provide a set of quite complex build environments in a single repo; it’s not exactly what I was asking but is related.

Sean.