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