Added a migrate output to the IHP flake

[mpscholten]

Potential fix for #1760

nix build .#migrate

# Now this runs the migration script, and automatically sets the working directory to the Project src
./result/bin/migrate

Likely (but untested) this can be used in nixos as:

environment.systemPackages = with pkgs; [ ihpApp.migrate ];

Then a global migrate command would be available

[kodeFant]

Tested now, with nix build --impure in the project and added as system package on the server. Both results in this error:

> Makefile:30: *** IHP not found! Run the following command to fix this:    nix-shell --run 'make .envrc'    .  Stop.

[mpscholten]

You're missing some steps from the UPGRADE.md (there's been some recent changes to the Makefile boilerplate)

[kodeFant]

Fixed the missing from upgrade guide 👍

nix build .#migrate in the project works (locally on my dev machine)

ihpApp.migrate didn't work.

I got it to run by adding the migrate script like this in the flake.nix.

            flake.nixosConfigurations."test-server-one" = nixpkgs.lib.nixosSystem {
                system = "x86_64-linux";
                specialArgs = inputs // {
                    environment = "production";
                    ihp = ihp;
                    migrate = self.packages.x86_64-linux.migrate;
                    ihpApp = self.packages.x86_64-linux.default;
                };
                modules = [
                    ./nixos/configuration.nix
                ];
            };

and then added migrate as arg to configuration.nix and added it as a system package.

{ config, pkgs, modulesPath, lib, environment, ihpApp, ihp, migrate, ... }:
{

  # ...
  
  # Add system-level packages for your server here
  environment.systemPackages = with pkgs; [
    migrate
  ];
  
  # ...
  
}

Now the error is

migrate: Application/Migration: getDirectoryContents:openDirStream: does not exist (No such file or directory)

Running nix build .#migrate compiles very fast though, so already at this point, I think we have improvement on deployment speed and minimizing disk usage on NixOS 👍

[mpscholten]

Does the test app have atleast one migration? Otherwise the Application/Migration directory might not been created yet

[kodeFant]

Ah of course, it didn't. Created now and it run properly 👍

[kodeFant]

It works smoothly, but there is one little issue:

Since it cds into the previously built ihpApp, projectSrc is for the previous build.

This makes it impossble to run the proper migrations before the nixos-rebuild.

Maybe we could take responsibility ourselves for cd-ing into the project directory and that it only provides the migrate binary directly?

[Eisfunke]

I'd recommend making this an app instead of an package, so you could directly run it with nix run .#migrate. Just put it under apps instead of packages, and add a type = "app". See: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-run.html#apps

Could look like this:

apps.default = {
      type = "app";
      program = pkgs.writeScriptBin "migrate" ''
          ${ghcCompiler.ihp}/bin/migrate
      '';
};

I would also recommend letting out the cd, by the way, that should be more flexible.

(also as a note, if I'm not mistaken, the migrate script isn't unique to a project but rather a IHP feature, so we could add it directly to the root IHP flake.nix so it could be used independently of having a specific project with nix run github:digitallyinduced/ihp#migrate, but that's something for another PR, probably together with expanding the root flake.nix in general)

[kodeFant]

Yeah, with multiple IHP apps in a server, it would make the most sense to use a nix app like that 👍

[kodeFant]

Tried out this in my fork based on @Eisfunke suggestion, and it seems to work well.

            apps.migrate = {
                type = "app";
                program = "${ghcCompiler.ihp}/bin/migrate";
            };

Then super nice to cd into project folder and run

nix run .#migrate

No need to pass from flake into systempackages with this solution

[kodeFant]

One consequence of the app approach is that the whole IHP app is being built twice, here and during the rebuild phase, so less efficient (e.g. more disk space/cpu/ram used, and longer build time if not hitting binary cache).

With the package appoach, it's instantly present.

So for that reason, I'm leaning towards a package without the cd to project path.

[mpscholten]

With the package appoach, it's instantly present.

Then let's stick with the package approach for now. I've just removed the cd PROJECT_DIR

[Eisfunke]

One consequence of the app approach is that the whole IHP app is being built twice, here and during the rebuild phase, so less efficient (e.g. more disk space/cpu/ram used, and longer build time if not hitting binary cache).

With the package appoach, it's instantly present.

So for that reason, I'm leaning towards a package without the cd to project path.

I'm not sure why it'd be built twice, the app should just use the package that was built before, and why that doesn't happecn with packages. Apps and packages are both just derivations, apps just have a defined execution start point.

We could also add both, by the way: a package with just the script, and then (possibly later in another PR) an app, which just call the script from the migration script package. That would be maximally flexible.

[kodeFant]

I'm not sure why it'd be built twice, the app should just use the package that was built before, and why that doesn't happecn with packages. Apps and packages are both just derivations, apps just have a defined execution start point.

@Eisfunke I'm not sure why myself. Either it has something to do with that it's impure according to nix standards (I think mainly because of import <nixpkgs> still present some places in the IHP nix files), or simply that a nix build is not using the same Nix store addresses as the one in the nixos configuration.

I have tried to dig into it, but I'm simply not smart enough to figure this out 😄

Edit: Well, come to think of it, it actually makes sense because the nix run action will address the new code, since this action is run before the system configuration is rebuilt.

[kodeFant]

suggest to prefix with ihp- to be on the safe side to avoid (probably unlikely) collision with nixpkgs with the same namespace

Suggested change

	pkgs.writeScriptBin "migrate" ''
	pkgs.writeScriptBin "ihp-migrate" ''

[mpscholten]

As long as this package is build with nix build it shouldn't cause any collision. I'd prefer to not introduce two names for the same binary, otherwise it will be confusing to other people in the future 👍