Relative paths and imported configurations

[stessaris]

This is not a bug report but just a request for the confirmation of the behaviour of mani w.r.t. the relative paths of imported configuration files. The documentation says that relative project paths are resolved w.r.t. to the config file; but in the case that projects are defined in an included configuration file, it's not clear whether they are resolved w.r.t. the path of the included or the including (root) configuration file. Apparently, mani takes the former approach (i.e., path of the included file, see below). I think that it's fine (actually rather useful), but I'd like to ask whether this is the intended behaviour and we can count on that also for future releases. I think that it should be mentioned in the documentation to avoid ambiguities.

The example below demonstrates the behaviour:

Directory structure

❯ tree
.
├── projects
│   ├── mani_projects.yaml
│   ├── project1
│   └── project2
└── tools
    └── mani.yaml

Configuration files

# projects/mani_projects.yaml
projects:
  project1: {}
  project2: {}

# tools/mani.yaml
import:
  - ../projects/mani_projects.yaml

env:
  MANI_WD: $(pwd)

projects:
  root:
    path: .

tasks:
  pwd: |
    target=$(pwd)
    common_part=${MANI_WD}
    back=
    while [ "${target#$common_part}" = "${target}" ]; do
      common_part=$(dirname $common_part)
      back="../${back}"
    done
    echo "project directory: ./${back}${target#$common_part/}"

Showing the directories of the projects

❯ mani -c tools/mani.yaml run pwd -a

TASK [pwd] *********************************************************************************************************

root | project directory: ./tools

TASK [pwd] *********************************************************************************************************

project1 | project directory: ./projects/project1

TASK [pwd] *********************************************************************************************************

project2 | project directory: ./projects/project2

[alajmo]

Correct, it should resolve with regard to the file that imports the project, similar to all programming languages.

[stessaris]

Correct, it should resolve with regard to the file that imports the project, similar to all programming languages.

Actually, I think that the way it works now is rather useful. You can drop a configuration file with the list of projects in the directory where you checkout your repos without worrying about the actual path; then, to use them you just need to include that file.

Aside, I noticed that you use os.ExpandEnv with the paths in the configuration file, so you get the bonus that environment variables are expanded. I didn't find that mentioned in the documentation, but it's extremely useful (e.g. used with a .env). I think you should mention it in the documentation, together with the order of evaluation of the env section(s) w.r.t. the rest of the configuration (you might want to use some of the variables in the paths).

Bottom line, I believe that the way mani works now it's fine, and it just need to be specified in the docs. BTW, changing the behaviour might break current configurations for some users (like mine 😉 ).

[alajmo]

Thanks, I will update the documentation to include that information as you say, it's very useful to know about it! Mani is still v1 so breaking changes will occur, but this won't be one of them!