Allow resolving from resolved schema using Manifest file.#1160
Allow resolving from resolved schema using Manifest file.#1160jsuereth merged 20 commits intoopen-telemetry:mainfrom
Conversation
…han just information on dependencies
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1160 +/- ##
=======================================
+ Coverage 79.9% 80.2% +0.3%
=======================================
Files 109 109
Lines 8586 8769 +183
=======================================
+ Hits 6865 7040 +175
- Misses 1721 1729 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…st multi-dependency test.
jerbly
left a comment
There was a problem hiding this comment.
This is a big one... I'm going to try this branch out. In the meantime, I found a couple of bugs and some nits.
| Some(self.registry.vdir_path().map_sub_folder(|path| { | ||
| if vdir_was_manifest_file { | ||
| match Path::new(&path).parent() { | ||
| Some(parent) => format!("{}/{resolved_url}", parent.display()), |
There was a problem hiding this comment.
Is this right? parent.display() will use os dependent separators, so backslashes in Windows.
There was a problem hiding this comment.
It will only do that if it's parsed or you use join. I wrote this on windows, and yes it's a bit awkward. Probably the thing that needs the MOST attention in this PR.
If you want me to refactor this, I'd be happy to try a bit.
| /// This can be either: | ||
| /// - A manifest of a published registry | ||
| /// - A directory containing the raw definition. | ||
| pub registry_path: VirtualDirectoryPath, |
There was a problem hiding this comment.
can we call it accordingly? could be confusing to see registry_path: http://otel.io/schemas ...
| pub registry_path: VirtualDirectoryPath, | |
| pub registry_location: VirtualDirectoryPath, |
or
| pub registry_path: VirtualDirectoryPath, | |
| pub registry: VirtualDirectoryPath, |
There was a problem hiding this comment.
Since manifest work today and folks use them, I didn't want to issue breaking changes.
I'm happy to move to something else and declare an alias here so we don't break.
Personally, I prefer registry_uri or registry_location better. The key thing to denote is this is a "virtual directory path" in Weaver vernacular, so it can point at directories inside a git repository or zip archive.
Should I update that now?
There was a problem hiding this comment.
now is great, I can also do it in #1106 (registry_uri sounds good and we'd align registy_url with it)
There was a problem hiding this comment.
Since this is a rather large PR - I'd rather do a dedicate PR for that change.
I think we could also look at moving from registry_manifest.yaml -> manifest.yaml in that one.
| #[error("Maximum dependency depth reached for registry `{registry}`. Cannot load further dependencies.")] | ||
| MaximumDependencyDepth { | ||
| /// The registry which has too many dependencies. | ||
| registry: String, |
There was a problem hiding this comment.
can we align on registry vs registry_id (above) vs registry_url ?
There was a problem hiding this comment.
Sure - I'm fine with either. Which do you think makes a better error message? URL or ID?
There was a problem hiding this comment.
I was playing with it in the #1106 and I'm thinking:
- registry_url | uri is required and necessary
idis now equivalent to name, it's not essential - can be optional on dependency
what if we had name() method that'd return name if it's known or fell back to url if not. We'd use it when reporting dependency errors and then called it registry_name (since that's what it called on dependency and in the manifest).
OR we should rename dependency.name and manifest.name to id and then use registry_id everywhere
There was a problem hiding this comment.
So - we need a "name" that's separate from "version" so we can isolate if we have a repeated/diamond dependency. That's actually orthogonal to this discussion, but made me realize we may have a bug in our dependency tracking on that front.
I'm a fan of name() method that falls back from human readable to the url. I need to sort through the whole codebase for id and fix it.
Do you think we can do that in a separate PR or do you want to clean that up now?
There was a problem hiding this comment.
yeah, let's do it as a follow-up - that'd be easier to review
There was a problem hiding this comment.
Yes! Let's do that in a follow up PR - This gets enough done I can start fragmenting my work into separate branches again without everything conflicting.
jerbly
left a comment
There was a problem hiding this comment.
Approving this as it's intended as a first in a series of PRs. In a subsequent PR it would be good to focus on usability around error reporting for mistakes made in manifest files. Is there a schema for the manifest file? And, we should tackle the todo!()s and .expect()s to avoid panics.
Agreed there is more cleanup to do here. @jerbly - Is there a todo or expect that's in non test code you're worried about? I'm aware of one around recursive dependencies that needs to be tackled, but I don't remember any |
I commented them for you.... You have |
|
Thanks @jerbly - I'll clean this up before submitting |
Fixes #1134
Should allow specifying a schema like in OTEP 4815.
http://my-schema.org/manifest/1.0.0resolved_schema_url, if available, on that manifest to resolve schema instead of grabbing.yamlfiles from the directory.resolved_schema_url, although this needs to be tested a bit.Thing not working yet:
manifest.yamlvs.registry_manifest.yamlas per OTEP 4815.