It is a breaking change in terms of behaviour (as pointed out in the old PR), because invocations like yamale a/b/c.yaml --schema=x/y/z/schema.yaml will now first check $PWD/x/y/z.yaml file for being a schema instead of starting from $PWD/a/b/x/y/z/schema.yaml and iterating over parents ($PWD/a/x/y/z/schema, $PWD/x/y/z/schema, etc). This changes the order in which schema files are used.
But, to be honest, I don't think this will cause many troubles, because the "fixed" behaviour corresponds to linux-way of referencing files, while the "old" behaviour was a bit counter-intuitive.
It is possible to implement a fix without changing the behaviour - basically check schema_name for being a file after all other attempts fail, but that will require a bit more changes and may complicate the code. I can implement it if you insist.
PR structure
There are 2 commits:
the first adds a test for the described scenario (and fails without the fix);
Check that
schema_name
is a valid file before iterating over parent directories ofdata_path
(the change is taken from quite old PR). Fix for https://github.com/23andMe/Yamale/issues/238 .Details
It is a breaking change in terms of behaviour (as pointed out in the old PR), because invocations like
yamale a/b/c.yaml --schema=x/y/z/schema.yaml
will now first check$PWD/x/y/z.yaml
file for being a schema instead of starting from$PWD/a/b/x/y/z/schema.yaml
and iterating over parents ($PWD/a/x/y/z/schema
,$PWD/x/y/z/schema
, etc). This changes the order in which schema files are used. But, to be honest, I don't think this will cause many troubles, because the "fixed" behaviour corresponds to linux-way of referencing files, while the "old" behaviour was a bit counter-intuitive.It is possible to implement a fix without changing the behaviour - basically check
schema_name
for being a file after all other attempts fail, but that will require a bit more changes and may complicate the code. I can implement it if you insist.PR structure
There are 2 commits: