Closed sneakers-the-rat closed 3 months ago
Attention: Patch coverage is 78.75000%
with 17 lines
in your changes are missing coverage. Please review.
Project coverage is 64.33%. Comparing base (
33ca663
) to head (c072024
). Report is 12 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
linkml_runtime/linkml_model/linkml_files.py | 78.75% | 17 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I think we should use pathib over os.path but either is infinitely better than hardcoding slash
just trying to follow the surrounding conventions :) ez to change
OK i went to swap out os.path.join
with pathlib
, and when i went to write a simple test that the generated paths exist, it turns out that most of them don't and there were a lot of other problems with the module, and since this is something i'd like to be able to rely on i went ahead and rewrote most of it.
Problems:
Format
and Path
enum didn't work.meta
, but there was no indication of thatSo this PR
Format
with an Enum
that keeps all the itemsFormat
and into _Path
FormatPath
within _Path
_build_path
rather than a string, because paths and URLs need to be built differentlyYou'll notice a lot of skipped tests. those are the ones that make network requests, which we need to cache in the same way we do with linkml
. I noticed this repo is still using unittest
in its CI, and didn't want to swap that out here too, so whenever we switch to pytest and add requests_cache
those tests shoudl automatically switch back on.
ope i guess the tests aren't being run? idk how unittest works. ¯_(ツ)_/¯ if ya want 'em they're there!
Thanks!
I'd like to test this with the main linkml
project before merging into main, as there are possibly some assumptions on the enum values in linkml.__init()__
and possibly other places.
I realize the current SOP for these kinds of tests is suboptimal, so we can strategize ways to improve things.
I also realize I'm being very conservative here because as you point out a lot of this is legacy and things didn't break when paths changed..
I'm pretty certain this PR represents a much better way of doing things than before. But another approach might be to eliminate dependency on this file altogether. The metamodel should largely not operate so differently from other models, and including the cross product of all schema modules times formats is not a scalable strategy.
I realize the current SOP for these kinds of tests is suboptimal, so we can strategize ways to improve things.
We could make a manually triggered action that runs the linkml tests along with the PR version of linkml-runtime, and make a branch protection rule that says that action must be run and passing before merging to main? that would make it so we don't have to run all the tests all the time, but since these are tightly coupled packages, ensures that changes here don't break linkml.
But another approach might be to eliminate dependency on this file altogether. The metamodel should largely not operate so differently from other models,
I think it would be very useful to be able to at least get a reliable handle to the metamodel schema files from linkml-runtime
- if not for perf reasons like using local schema rather than always dereferencing, then for introspection reasons. i agree that metamodel shouldn't be that special cased, but it still is a little special.
I could go either way on the github links part, i am not really sure when that would be useful.
including the cross product of all schema modules times formats is not a scalable strategy.
true, but with caching these tests would be pretty fast:
get
s are not that expensive, but still sorta expensive, but if we have a module that says it provides links, then we should ensure that they work.so if perf is a concern, imo we should drop the link generation part.
I think it would be very useful to be able to at least get a reliable handle to the metamodel schema files from linkml-runtime
oh absolutely - my point was just that having an enormous list of N x M constants is not necessarily the best way to do this
ah i see. yes totally agreed - ideally this metadata should come from the generators, no? or maybe projectgen? i'm actually still a little foggy on the workflow for updating the linkml_model
module but ya for sure on the same page re: a ton of constants not being a good longterm strategy
the thing we want here is 'given the metamodel and {projectgen or however the linkml_model
is generated}, we should expect to have these files and these links,' so if it was possible to introspect that expectation from the generation process that sounds more sustainable. maybe this PR is just to fix this module for now and we make that as a TODO on it?
on windows, the paths for local model files look like this:
which seems to work, but it probably shouldn't.
change hardcoded
/
separators to useos.path.join
to make paths correct on windowsRelated to: https://github.com/linkml/linkml/pull/1976