Closed sneakers-the-rat closed 3 weeks ago
ping on this :) would like to remove my monkeypatch <3
This is blocking some functionality I'm trying to implement with LinkML as well. Is there an ETA on merge/release?
it looks like this is the error blocking atm:
Because linkml-dataops (0.1.0) depends on linkml-runtime (>=1.1.6)
and no versions of linkml-dataops match !=0.1.0, every version of linkml-dataops requires linkml-runtime (>=1.1.6).
So, because linkml depends on both linkml-dataops (*) and linkml-runtime (0.0.0) @ file:///home/runner/work/linkml-runtime/linkml-runtime/linkml-runtime, version solving failed.
Error: Process completed with exit code 1.
That was a bug with the upstream test runner that has since been fixed - trigger a manual run of that upstream test action and it should work ;)
tried to trigger a run, but i don't have privileges to run it manually for this repo, and it only runs when there is an approval event, which is proving to be increasingly annoying and i'm thinking we should just always run the upstream test action lol
Fix: https://github.com/linkml/linkml/issues/1228 Specifically: https://github.com/linkml/linkml/issues/1228#issuecomment-1712390959
1228 describes two problems, one having to do with relative imports when using an already-loaded
SchemaDefinition
object withSchemaView
, which has already been fixed, and another, where multiple layers of relative imports wouldn't work.eg. Say you have three schema such that...
main.yaml
imports./a/a_schema.yaml
./a/a_schema.yaml
imports./b/b_schema.yaml
(or,./a/b/b_schema.yaml
from the POV ofmain.yaml
)Then
a_schema
would be correctly imported, butb_schema
wouldn't be, since it would previously be resolved relative to the directory ofmain.yaml
Additionally, one might anticipate schema developers to use an
index.yaml
style of creating nested schemas, where there might potentially be many schemas with a filenameindex.yaml
in different directories - we need to preserve those same-named schemas while also not getting into import cycles.This simple lil PR does that, and tests a bunch of different permutations of nth-layer imports (see
tests/test_utils/input/imports_relative/README.md
)This has to be done in the
imports_closure
method (rather than in the schema_wrap method, or makingimports_closure
pass the loaded schema as thefrom_schema
argument) in order to preserve same-named schemas in theimport_map
, which uses the string of the import (rather than eg.schema.id
orschema.name
) as the key. Note that while this does mean that the key inimport_map
will be different than the literal import string in the nth-layer schema (eg. in the above example, the key would be./a/b/b_schema.yaml
while the actual import statement was./b/b_schema.yaml
), that string is not meaningful to the origin schema, and the relative import from its location is unambiguous and allows for deduplication (which is tested)yet another "two lines of code but 1000 lines of tests" PR lol