| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of passing around untyped tuples for cache keys, lets have
a clearly typed object for this.
This makes for more readable code, and additionally corrects the
data model statement of intent that some cache keys should be displayed
as "dim", instead informing the frontend about whether the cache key
is "strict" or not, allowing the frontend to decide how to display
a strict or non-strict key.
This patch does the following:
* types.py: Add _DisplayKey
* element.py: Return a _DisplayKey from Element._get_display_key()
* Other sources: Updated to use the display key object
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As a rule, throughout the codebase we should not be using internal
ProvenanceInformation objects in our APIs, but rather Node objects.
This is because ProvenanceInformation is generated on the fly from
a Node object, and it is needlessly expensive to instantiate one before
it is absolutely needed.
This patch unilaterally fixes the codebase to pass `provenance_node`
Node objects around as arguments rather than `provenance` ProvenanceInformation
objects.
|
| |
|
|
|
| |
Makes the warning fatal if we fail to stage a file because it would have
otherwise overwritten a non-empty directory.
|
| |
|
|
|
| |
Used to define the behavior of multiple calls to Element.stage_artifact()
and Element.stage_dependency_artifacts()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large breaking change, a summary of the changes are that:
* The Scope type is now private, since Element plugins do not have
the choice to view any other scopes.
* Element.dependencies() API change
Now it accepts a "selection" (sequence) of dependency elements, so
that Element.dependencies() can iterate over a collection of dependencies,
ensuring that we iterate over every element only once even when we
need to iterate over multiple element's dependencies.
The old API is moved to Element._dependencies() and still used internally.
* Element.stage_dependency_artifacts() API change
This gets the same treatment as Element.dependencies(), and the old
API is also preserved as Element._stage_dependency_artifacts(), so
that the CLI can stage things for `bst artifact checkout` and such.
* Element.search() API change
The Scope argument is removed, and the old API is preserved as
Element._search() temporarily, until we can remove this completely.
|
| |
|
|
|
|
|
|
|
| |
This adds a new _ProjectInformation type to types.py which
is returned by the new Project.loaded_projects() API, supported
by a new internal LoaderContext.loaded_projects() function.
This allows the frontend some helpful information to print about
the loaded projects in the session heading.
|
| |
|
|
| |
Also fix linting errors coming with new version of pylint
|
| |
|
|
|
| |
This ensures that we get as 'default' what the user needs to enter in
the command in the manpages
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does not make sense to keep in the public API surface
documentation. As we are heading towards a release of 2.0, this
represents a "reset" in public API, and older annotations only
serve to clutter the documentation with information that is not
relevant to the reader.
Everything which is public at the time of the 2.0 release can
be considered available "Since: 2.0" implicitly (as this is
going to be the starting point of this new stable API).
It will make sense to start adding these annotations again for any
added API in 2.2 and forward.
|
| |
|
|
|
| |
'Consistency' is not needed anymore, now that we have everything in
place to not use it
|
| |
|
|
|
|
|
|
|
|
|
| |
This removes the early call to get whether sources are locally cached
in `_update_source_state` by delegating it to the call of `is_cached`.
Once it is cached, the element is assumed to stay that way for the
duration of the pipeline, we can therefore cache the result once it is
true.
Also remove `Consistency.IS_CACHED`, which is not used anywhere else.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PipelineSelection is one of the few stringy types that weren't
converted to FastEnum, presumably because we lacked a mechanism for
only allowing a sub-set of options as CLI arguments.
We've re-designed this since, and as part of the UI/UX refactor we'd
like to generally clean this, but that is probably still a while out.
Since that hasn't happened, for now, this adds a feature to the
FastEnumType that allows specifying only a subset of values is allowed
for a specific command, so that we can use the type as a proper
enum.
We also get rid of a number of accidental uses of strings, and move
PipelineSelection to buildstream.types so that we don't have a
significant import overhead for it.
|
| |
|
|
|
|
|
| |
As discussed over the mailing list, reformat code using Black. This is a
one-off change to reformat all our codebase. Moving forward, we
shouldn't expect such blanket reformats. Rather, we expect each change
to already comply with the Black formatting style.
|
| |
|
|
|
|
|
|
|
|
| |
As a first step, add type hints to variables whose type `mypy` cannot
infer automatically. This is the minimal set of type hints that allow
running `mypy` without any arguments, and having it not fail.
We currently ignore C extensions that mypy can't process directly.
Later, we can look into generating stubs for such modules (potentially
automatically).
|
| |
|
|
|
|
| |
This allows removing completely the '_node_get_option_str' on context
and ensures every method relying on a few set of keys set their errors
consistently
|
| |
|
|
| |
Also add helpers for the cli to be able to represent 'FastEnum' directly
|
| |
|
|
|
|
|
|
| |
This adds a method to ensure that a value is from a set of valid values
and raises an error message accordingly.
- Define Enum types for each of the relevant cases
- Adapt call places that were doing such things manually
|
| |
|
|
|
|
| |
This allows for stronger guarantees when checking the level of
consistency since it will only be comparable with itself, and ensures
unicity
|
| |
|
|
|
|
|
| |
'Enum' has a big performance impact on the running code. Replacing
it with a safe subset of functionality removes lots of this overhead
without removing the benefits of using enums (safe comparisions,
uniqueness)
|
| |
|
|
|
|
| |
Now that __update_ready_for_runtime() and
__update_strict_cache_key_of_rdeps() have been introduced,
we no longer need to recursively update the state of elements
|
|
|
This was discussed in #1008.
Fixes #1009.
|
