Hi again,
On Tue, 2020-07-28 at 02:11 +0900, Tristan Van Berkom wrote:
> Hi Douglas,
[...]
> > 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 ?
After sleeping on this I feel more strongly in favor of allowing this
on all dependencies regardless of `type`.
The worst case scenario is that it happens to not be used with runtime-
only dependencies much.
One thing I can say with certainty, is that information about runtime
dependencies is certainly relevant, even at build time.
For a silly example: lets say that my program needs to run one or more
programs at runtime, then the element I'm building still needs to know
things like where that runtime dependency is installed, which might be
in a custom prefix.
While this kind of information is more suitable to encode into a
project using regular variables and includes, or public data set on
those dependencies, I think that the general rule stands that
information about a runtime dependency is still relevant information,
and that there can be unpredictable constructs where it can be suitable
to have such information configurable on a custom Element class on a
per-dependency basis.
By this logic, I think it would not be sensible to limit/disallow
parsing of custom YAML based on the dependency `type`.
Cheers,
-Tristan
