Add option to build on the target host

[PhilTaken]

This PR adds the option to build the derivation on the target server instead of locally.
The derivation will first be uploaded to the target system and then built in the remote store.
Any required external dependencies will be fetched to the target host using the target system's substituters.

Fixes #12

[rvem]

Can you also add --remote-build flag to the command line arguments of deploy?

[PhilTaken]

as a "build all deployments on the respective target servers" override?
the current implementation only builds selected builds remotely, but that could be a good idea

[rvem]

as a "build all deployments on the respective target servers" override?

Yes, I imagine that it might be useful when one doesn't have decent internet connection or has limited traffic

[hazelweakly]

When I try this out and run it on my machine, it fails on line 181

  if !Path::new(
        format!(
            "{}/deploy-rs-activate",
            data.deploy_data.profile.profile_settings.path
        )
        .as_str(),

because, as the system is remote and the closure was built remotely, this path is not going to exist in my store or on my system.

I'm not sure I have a great solution for that, but I wanted to point that out cause I'm trying this out in anticipation of managing remote machines via macOS

[rvem]

Perhaps, in this case, activation should happen on the target as well 🤔

[rvem]

FTR, I have the same issue even with NixOS -> NixOS deployment 🙈

[hazelweakly]

How I ended up "sorta solving this" myself was to take the path that deploy info spits out and then dead-reckoning run a little bash function with that path as the input.

function activate-on-host(){                                                            
  printf -v profile %q "$1"                                                          
  ssh user@FQDN "export PROFILE=$profile ; bash $profile/deploy-rs-activate" 
}                                                                                    

Which, indeed, simply runs the activation on the target

[PhilTaken]

I see, I did not encounter that error, very likely because I had it built locally before I tested remote building

the push_profile function does quite a lote at this point and most of it assumes the derivation is being built locally

splitting it up into a function to handle building locally and another to handle remote builds should resolve some of those difficulties

[PhilTaken]

besides, contrary to its name it also handles the building, not just the pushing 🤔

[PhilTaken]

@hazelweakly could you try again with the newest changes?

make sure to gc before 😉

[rvem]

Tried both remote and non-remote builds, worked for me 🎉

[rvem]

Tiny nitpick:

Suggested change

	.arg("--eval-store") .arg("auto")
	.arg("--eval-store").arg("auto")

[hazelweakly]

@PhilTaken I can confirm that it works for me too (remotely). Thank you! This is very nice :)