Configurable nix options and substitute-on-destination #83
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adamtulinius
approved these changes
Oct 27, 2019
flokli
reviewed
Nov 20, 2019
|
Sure! Let's see if we can get #91 squeezed in the release as well. :) I'll get back to you on that. |
|
Thanks! |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Trying to make morph more configurable by allowing for pass-through of nix.conf options. It's now possible to provide an attribute set of configuration options (
nixConfig) for each deployment. These options will be passed to bothnix-buildandnix copy. Unfortunately, because of the way morph does things, it's not possible to set nix config on a per-host level.In an effort to also try and fix #73, i've added
substituteOnDestinationas a deployment module option. This option applies with per-host granularity.While working on this, I considered just making the entire nix command-line available to the user, which would make any possible flag and option configurable. I rejected that idea for now though, because it turns out to be complicated. There are many permutations of per-host and per-deployment options and there should be a way in the API to then also distinguish flags intended for
nix-buildandnix copyor evennix eval.TLDR; I figured that would make the API too complicated at this point. I hope that this PR at least solves "some" problems.