Allow custom YAML file defined outside of Nix

[YvanDaSilva]

Should this flake also allow to write a process-compose.flake.yml similarly to how 'just' flake does it via shell hook?

https://github.com/juspay/just-flake

This would allow composability with non flake defined processes.

[srid]

Can you elaborate further?

[YvanDaSilva]

Hello @srid,

First, appologies, I didn't notice that discussions where open on the GH repo.

Concerning this effort, I mean that process-compose like just can use "composition".

• Just: https://just.systems/man/en/imports.html import? just-flake.just in a local justfile allows to import the just recipes defined in nix flake. This allow to run something that is not part of the nix flake for example. The just-flake.just is created in the /nix/store and then linked back as follows https://github.com/juspay/just-flake/blob/main/flake-module.nix#L55
• process-compose: https://f1bonacc1.github.io/process-compose/merge/ process-compose.override.yml and extends can both be used in different ways to augment the original process-compose definition. This can be used for many things, lets say you want to setup a vpn, a shell, some container, or whatever else that is not part of the nix flake. It is also possible to pass multiple -f arguments.

process-compose by default loads process-compose.yml and process-compose.override.yml as pointed by their documentation.
If we were to link process-compose.yml back as "process-compose-flake.yml" it could let the user choose to start process-compose locally and create their own process-compose.yml that is not part of the nix flake or any other yml that will allow them to run non flake services, tasks, etc.

Let me know if my explanation is clear enough.

I come to this because I was trying just flake, flake services, process-compose flake and realized that I would still like to let someone else run everything without them requiring nix.
Nix would be the prefered way, but at least there would be another possibility by installing / managing their own tools.
Just flake support this case very well, but process-compose-flake does not, and I was wondering if that would be of interest to have it? It doesn't seem like a large effort.

[srid]

Okay, but I still don't know what the original use-case is. When you say "repo", what is the nature of this particular application? What is the purpose of the application? What is its use? What services is it spinning up through process-compose? Etc. Re: "They might not get all the nice things I define in nix." - what are those nice things, specifically, in the context of this application? And why are they optional?

The reason I ask is - generally when adding any new feature requested, I always start from the most concrete actual use-case. The concrete need then informs particular design decisions.

[YvanDaSilva]

@srid Fair, I understand your POV.
Lets go step by step.
Nature of the app:

• simple 3 tier app, backend, db, frontend
• nice things provided inside nix are "treefmt", cached builds, db setup, healthchecks, etc. None of these things are required per say. One can easily just clone the repo and live fine without ever doing nix develop, or nix run, etc.

However, I don't want to duplicate that behavior twice, with lets say docker-compose or some shell scripts, makefile, etc. If I can avoid it.
I just want to expose a nice way to run the 3 tier app with something as simple as process-compose and just.
If I can limit the stuff that I need to duplicate in order to run the app in a non nix env. I would be verry happy. (Less work)

So by using the same "tooling" that I use in nix, I can do almost the same, AFAICT.
Example for the db, I can provide a very simple just task to start a postgresql in a container which is more likely to be already present in anyone's dev toolbox than nix.

TLDR: Nix, as amazing as it is, is still niche and I don't want to force anyone working with my code to have to rely on it to run or build it.

[srid]

Can't you then do this in your flake, outside of process-compose-flake, by using config.outputs.settingsFile directly?

process-compose-flake/nix/process-compose/settings/default.nix

Lines 107 to 113 in 1012530

	outputs.settingsFile = mkOption {
	type = types.attrsOf types.raw;
	internal = true;
	description = ''
	The settings file that will be used to run the process-compose flake.
	'';
	};

Then you can use extend or -f as you see fit (combining Nix-generated one with your hand-written one).

I don't see what exactly is being requested here that process-compose-flake itself has to implement.

[YvanDaSilva]

I haven't tried that.
Note that I don't have a perfect expertise of nix, nor of the process-compose-flake module.
I saw that settings but didn't understand what it meant.
So you can create services in flake and also set a target file to run ?
What happens when you set that setting, is this settingsFile the process-compose.yml?

As you can see :) it's not fully clear.

I simply compared just-flake behavior, and that behavior is fairly clear as just-flake.just is created in the /nix/store and then linked back to folder where the flake is.

If passing this settingsFile is enough, I will have a look then :)

[srid]

process-compose supports both YAML and JSON. You can do writeTextFile and toJSON on config.outputs.settingsFile (see here) to create the JSON file, and then feed it to process-compose binary however you wish (outside of Nix).

Basically, you can use this module just to create the settings file, and compose it and run it as you wish.

[YvanDaSilva]

Thank you, that sounds great, I will try that!