Hi Douglas,
On Mon, 2020-07-27 at 11:33 +0100, Douglas Winship wrote:
> This sounds like a great idea.
>
> In the example, the new config attribute was used under the 'depends:'
> key. I was wondering how it would work 'build-depends:' and
> 'runtime-depends:'.
>
> I'm assuming it could be used under 'build-depends' in exactly the same
> way as the regular 'depends'?
Note that:
build-depends:
- foo.bst
Is only shorthand for:
depends:
- filename: foo.bst
type: build
The same goes for `runtime-depends` which is shorthand for declaring a
dependency with `type` set to `runtime`.
The default for the dependency type[0] is to be both a build and
runtime dependency.
The values for `depends`, `runtime-depends` and `build-depends` are all
the same "string-or-dict" format, where a simple string only depicts
the element path to depend on, or the full dictionary[1] can be used to
set other attributes of the dependency relationship.
The dependency dictionary in this proposal would be extended to support
an additional `config` section which would be custom YAML expected to
be parsed by the Element class on which the dependency is declared, and
would not have any limitation as to which dependency type[0] is allowed
to accompany that dictionary.
> But I don't think there would be a meaningful way to use it under
> 'runtime-depends'. Is that right?
Interesting point.
The artifact of a dependency that is only needed at runtime is not
accessible to an element at build time (however the Element in the data
model is available), which indeed would mean that a given Element
implementation would not be able to do anything meaningful *at build
time* with custom semantics.
This is an interesting choice I'm not sure I have an answer to today,
should we only allow parsing custom YAML on build dependencies, and
call it an error to specify `config` on a dependency that is strictly a
`runtime` dependency ?
* On the one hand, I favor not having this restriction, inventive
minds may come up with useful things to do with this, and I'd
prefer a more symmetrical API.
* On the other hand, observing a runtime-only dependency in the
data model can have bad side effects - especially given that by
current definitions, a runtime-only dependency might have public
data that is not yet mutated.
On this particular hand however, these bad side effects could
present themselves regardless of this added feature, and I also
think there are good arguments to remove the ability to dynamically
mutate public data in `Element.assemble()`.
Cheers,
-Tristan
[0]:
https://docs.buildstream.build/master/format_declaring.html#format-dependencies-types
[1]:
https://docs.buildstream.build/master/format_declaring.html#expressing-dependencies
