gtristan commented on code in PR #1997:
URL: https://github.com/apache/buildstream/pull/1997#discussion_r1995815595
##########
src/buildstream/source.py:
##########
@@ -262,10 +262,123 @@ def __init__(
@dataclass
class AliasSubstitution:
+ """AliasSubstitution()
+ An opaque data structure which may be passed through
+ :func:`SourceFetcher.fetch() <buildstream.source.SourceFetcher.fetch>` and
in such cases
+ must be provided to :func:`Source.translate_url()
<buildstream.source.Source.translate_url>`.
+ """
+
_effective_alias: str
_mirror: Union[SourceMirror, str]
+class SourceInfoMedium(FastEnum):
+ """
+ Indicates the meduim in which the source is obtained
+
+ *Since: 2.5*
+ """
+
+ LOCAL = "local"
+ """
+ Files stored locally in the project
+ """
+
+ ARCHIVE = "archive"
+ """
+ An archive file
+ """
+
+ GIT = "git"
+ """
+ A git repository
+ """
+
+
+class SourceVersionType(FastEnum):
+ """
+ Indicates the type of the version string
+
+ *Since: 2.5*
+ """
+
+ VERSION = "version"
+ """
+ The upstream version string, which may be semantic version
+ """
+
+ COMMIT = "commit"
+ """
+ A commit string which accurately represents a version in a source
+ code repository or VCS
+ """
+
+ SHA256 = "sha256"
+ """
+ An sha256 checksum
+ """
+
+ DIGEST = "digest"
+ """
+ A CAS digest representing the unique version of this source input
+ """
+
+
+class SourceInfo:
+ """SourceInfo()
+
+ An object representing the provenance of input reported by
+ :func:`Source.collect_source_info()
<buildstream.source.Source.collect_source_info>`
+
+ *Since: 2.5*
+ """
+
+ def __init__(self, url: str, medium: str, version_type: str, version: str):
+ # XXX assert medium and version_type are valid values for the enums
+
+ self.url: str = url
+ """
+ The url of the source input
+ """
+
+ self.medium: str = medium
+ """
+ The :class:`.SourceInfoMedium` of the source input
+ """
+
+ self.version_type: str = version_type
Review Comment:
This is a good question.
My initial thoughts were that some plugins, e.g. some of the git plugins out
there in the wild, provide `git describe` format for their `ref`, and thus
would provide both contexts in the same string, but always something useful and
precise (e.g. merely a tag, or a tag + number of child commits + commit sha).
Another thought I have been playing with along these similar lines is that
it may be possible for `Source` classes to require `Source.fetch()` be run and
that they have access to the staged sources in order to implement
`Source.collect_source_info()`.
Also, we can consider formatting of reports separately, as long as we are
strict about what the version type *means*, so we could potentially have a
version type which is a *"git sha or git describe"* output, and parse these
strings into more fancy reports when generating html and such, if we want to
*display* the version and sha separately.
That said, indeed I wonder how one could possibly determine the *version* of
a tarball... and in that light I wonder how meaningful the version of a tarball
is.
--
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]
