Enable to specify how relative paths of the extended file are resolved by `extends` keyword

[kota65535]

Feature Request

Use Case:

First of all, thank you for creating such a great tool!

Recently, process-compose introduced the extends keyword which makes it easier to merge multiple configuration files. I'm trying to apply this feature to monorepo, which has multiple packages and dependencies.

Assume we have the following monorepo:

.
├── db
│   ├── db-start.sh
│   └── process-compose.yaml
└── server
    ├── process-compose.yaml
    └── server-start.sh

process-compose.yaml in db package:

processes:
  # starts DB process
  db-start:
    command: ./db-start.sh

process-compose.yaml in server package:

extends: ../db/process-compose.yaml

processes:
  # starts server process, which depends on `db-start` process of the `db` package:
  start:
    command: ./server-start.sh
    depends_on:
      db-start:
        condition: process_healthy

Currently, the relative paths in the extended file (process-compose.yaml in db package) are resolved relative to the extending file (process-compose.yaml in server package). So running process-compose up in server directory results in the following error, because we don't have db-start.sh in server directory.

bash: line 1: ./db-start.sh: No such file or directory

It would be helpful if we have a way to specify how relative paths of the extended file are resolved (the file they originated in or the extending file).

Proposed Change:

Maybe something like this?

extends:
  file: ../db/process-compose.yaml
  path_resolution: extended # or extending

Available values are:

• extended: The relative paths in extended configuration file are resolved relative to the file they originated
• extending: The relative paths in extended configuration file are resolved relative to the file having extends keyword

I think we can come up with more obvious word.

Who Benefits From The Change(s)?

Users using extends keywords, especially working with monorepos.

Alternative Approaches

[kota65535]

Syntax like Go Task's includes might be preferable.

[smeijer]

I agree with this. Personally, I wouldn't go for making it configurable, but IMO, relative paths should be relative to the file they're defined in. The resolution of a path shouldn't change based on from where it's extended.

If one needs to adjust the path, they can override it in the extending file.

[F1bonacc1]

Hi @kota65535,

I think it's a good proposal. I think it will make more sense to keep it simple and to set the working_dir (for each process):

1. If empty - set it to be the location that contains the extended process-compose.yaml
2. If not empty and absolute dir - no change.
3. If not empty and relative dir - join extended process-compose.yaml location with the defined working_dir.

What do you think?