`extends` should be evaluated relative to the config file, not the current working directory

[btrautmann]

I created this issue originally, but upon doing more investigation I realized this is really just an issue (or oddity) with yamllint itself.

Basically, all the tooling I'm used to that has an "extends" feature in yaml files allows relative paths to be evaluated relative to the file itself, not the current working directory.

In my setup, we have:

./.yamllint and ./.github/.yamllint, where the latter extends the former via extends: ../.yamllint

However, running yamllint -c .github/.yamllint .github/ from root and yamllint -c .yamllint . yield different results. When run from the root (the default behavior on Github Actions), an error is thrown (the one indicated in the above ticket). When run from the .github directory, the command succeeds.

I searched prior issues and saw a couple that touched on relative paths, but I don't think any of them specifically touched on this issue (which was surprising). Please feel free to point me to any issues I may have missed.

Thanks!

[btrautmann]

FWIW, here is an example of tooling I'm used to (dart analyze) that follows the convention I'm suggesting:

# analysis_options.yaml
include: ../analysis_options.yaml

analyzer: 
  errors: 
    invalid_annotation_target: ignore

In this case, running dart analyze from either the directory containing this file OR the parent directory yield the same results.

[adrienverge]

Hello Brandon,

Thanks for the report.

Indeed there are similar issues about relative paths but for ignore-from-file, and an ongoing pull request at #701.

I understand your point and agree I would be practical and maybe more intuitive if extends: … was evaluated relative to the file that contains it, rather than relative to the current working directory.

However if we change this behavior, it could break many users processes (who expect the "old and awkward" behavior), so it should be done very cleanly, with new tests for all possibles cases, and advertised properly in the changelog.

[btrautmann]

Hello Brandon,

Thanks for the report.

Indeed there are similar issues about relative paths but for ignore-from-file, and an ongoing pull request at #701.

I understand your point and agree I would be practical and maybe more intuitive if extends: … was evaluated relative to the file that contains it, rather than relative to the current working directory.

However if we change this behavior, it could break many users processes (who expect the "old and awkward" behavior), so it should be done very cleanly, with new tests for all possibles cases, and advertised properly in the changelog.

Couple thoughts:

• It feels like fix: ignore-from-file relative to config file #701 shouldn't go in without also making extends have the same behavior, right? If ignore-from-file works the way I'm describing in this issue, but extends doesn't, that may be doubly confusing.
• This should all be wrapped up within a breaking-change release, which feels very reasonable to me, do you agree?