gtristan commented on PR #1997: URL: https://github.com/apache/buildstream/pull/1997#issuecomment-2816508216
@abderrahim, @juergbi Some additional thoughts now that I get down to business... ## Abolish the whole freeform string entirely In our meeting this week, we discussed that we would prefer to keep the flexibility and not require that `SourceInfoMedium` and `SourceVersionType` enumeration values be strictly followed (resulting in the requirement of many distinct values being introduced into the core)... **And** we discussed that we would instead prefer freeform strings for these attributes of the `SourceInfo` object, and that we should: * Automatically encode the plugin *"kind"* name into the SourceInfo reported * Provide a machine readable way (e.g. via `bst show`) to provide the plugin provenance information for given plugin kinds * Have the deciding information about the *meaning* of the `SourceInfo.version` string (e.g. is it a git sha or is it a sha256sum of a downloaded file or what), documented in the governing source plugin documentation individually. Ok, this all makes sense, however now that I look at it again, I no longer see any need whatsoever of having the `SourceInfoMedium` or `SourceVersionType` information present **at all** in the `SourceInfo` object. Instead we only need the following members: * `kind`: Plugin "kind" string * `version`: The machine readable *precise* version (e.g. git sha, CAS/docker digest, sha256sum, etc) * `version_guess`: The plugin assisted *guess* at what the human readable version is Given that we can obtain the precise plugin and version for a given `kind`, and that that governing plugin documentation **must** already document precisely *what it means* in the `version` member, the whole concept of the `medium` and `version_type` are obsolete and essentially meaningless. ## Automate the plugin specific documentation As a separate thought, I feel like the need to associate the governing documentation of *what a `version` means* with a given *plugin `kind`* is overly onerous. I think that while this can continue to be true, we could make this easier in the following way: * Source plugins *must document the meaning of the `version`* in their `Source.collect_source_info()` implementation's docstring * BuildStream can then inspect that docstring at runtime and provide a way to also report that docstring in some machine readable way. This approach would allow, from both a `collect_manifest` plugin perspective, **and** from a CLI wrapper script perspective, to generate reports which both: * Have a section including the governing plugin documentation about the *version* for each plugin "kind" in the context of that pipeline * Have the SourceInfo members for each Source instance, including the plugin "kind" name in the context of that pipeline -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
