abderrahim commented on PR #1997: URL: https://github.com/apache/buildstream/pull/1997#issuecomment-2816573995
> 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 > > * `url`: Unaliased upstream full URL (not mirrored URL) > > * `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 I feel this pushes it too far in the opposite direction. This assumes a single mapping between a plugin kind and a (medium, version_type) pair, which isn't always the case. For instance the cargo2 plugin can use both tarballs and git repositories. Also plugins like git, git_repo and git_module are very similar in what they provide and having a user of the API need to know all the different plugins seems unweildy. The main goal behind having an API like this is to reduce the amount of knowledge that a user of the API needs about specific plugins. > 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. "We" as humans, sure. But as a script using the API, having a well defined meaning for the version field and a standardized way to define things is very important. Even if a new value comes up later, then depending on the use case the script could output a warning or outright fail. But having it fail on every new plugin isn't scalable. -- 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]
