Load `.pc-env` from directory relative to `yaml` file

[FPtje]

Feature Request

In https://github.com/F1bonacc1/process-compose/issues/194 (v1.18.0), the ability was added to load .pc-env files. This is really nice, and solves a problem of setting the default port when loading a yaml file with a service that runs on port 8080.

I did notice, though, that .pc-env is only loaded from the current working directory. Given this directory structure:

foo/
  - process-compose.yaml
  - .pc-env, containing PC_PORT_NUM=18080

The following will work:

$ cd foo
$ process-compose up -f process-compose.yaml

But the following will not, as in, it will not load the .pc-env, and start listening on port 8080:

$ process-compose up -f foo/process-compose.yaml

Use Case:

The settings that are put in .pc-env are coupled to the process-compose.yaml file. It would be nice to have a single command to run this process-compose.yaml file, with its .pc-env from anywhere. It's a little bit surprising that this behavior is different when you run the yaml file from a different directory.

Proposed Change:

Also look for .pc-env in the directory of the process-compose.yaml file. Regarding precedence, if there is a .pc-env in both the current working directory and the directory relative to the yaml file: I don't have a strong preference. One could be loaded instead of the other, or they could all be loaded, with the more specific .pc-env file overriding the settings of the more generic .pc-env file.

Who Benefits From The Change(s)?

People who have a service running on port 8080 in their process-compose configuration

Alternative Approaches

I don't have other ideas besides the ones mentioned in the original issues, which take a different approach entirely.

[F1bonacc1]

Hi @FPtje,

Thank you for your feedback. On the one hand this feature makes a lot of sense on the other, in some scenarios it creates a chicken or the egg problem. One of the environment variables that can be defined in .pc_env is PC_CONFIG_FILES therefore loading colocated .pc_env becomes an issue. Also for other scenarios .pc_env should be loaded before any other flag, to override all the defaults.

Would you happen to have any recommendations on how to address those concerns?

Another point. Have you considered an alternative approach in which you have multiple preset configuration directories? For example:

PRESET-A
# .pc_env
PC_CONFIG_FILES=/path/to/compose.yaml
PC_PORT_NUM=18080

PRESET-B
# .pc_env
PC_CONFIG_FILES=/path/to/another/compose.yaml
PC_PORT_NUM=28080

[FPtje]

Those are some good questions! I think I may have misunderstood the relationship between process-compose the executable, the compose.yaml file and the .pc_env file. My understanding was that the .pc_env file conceptually belonged as a pair with compose.yaml, where compose.yaml defines the services, and the .pc_env defines additional settings to pass to process-compose. From that point of view, it was surprising that the .pc_env was read from the current working directory, rather than the same directory as compose.yaml.

From your questions, I read that the .pc_env file belongs belongs as a pair with process-compose the executable. From that perspective it makes sense that it always loads the .pc_env from your current working directory.

I suppose this issue then flows from a misunderstanding on my part. I guess as a solution I can run env --chdir=~/foo process-compose.

I'll close this issue, since my misunderstanding has been clarified, and I have a solution. Thanks!