gtristan commented on PR #1997: URL: https://github.com/apache/buildstream/pull/1997#issuecomment-2816625478
[...] > > 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. Yeah, I was just now thinking about this... its unfortunate :-/ > > 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. While this point is now moot due to the preceding point, I would have agrued that it is in fact humans which need to know *"What to do with this specific plugin kind"* when encountering one programatically. This is the same kind of documentation that will be needed for representing what the meaning of these free form strings are. Do you think there is any reason to have 2 different strings (one for the medium and one for the version) ? Or would it be sufficient to have a single string to define how a given `SourceInfo` instance behaves ? -- 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]
