Hi,
On Wed, 2020-08-05 at 17:00 +0200, Jürg Billeter wrote:
> Hi,
>
> On Sun, 2020-08-02 at 22:30 +0900, Tristan Van Berkom wrote:
> > [...]
> >
> > Solution 2: Remove runtime dependencies from build input
> > --------------------------------------------------------
> >
> > * This approach would be to ensure that Element plugins do not have
> > access to runtime dependencies.
> >
> > * As such this proposal would not allow custom configuration of
> > runtime dependencies, because they would not be considered as
> > input anymore.
> >
> > * Similarly, Element.dependencies() would no longer be allowed to
> > see runtime-only dependencies.
>
> An element should still be able to iterate over the runtime
> dependencies of a build dependency, though. We need to be careful not
> to restrict `Element.dependencies()` too much.
This is what we currently call `Scope.BUILD`, the build scope includes
runtime dependencies of build dependencies.
I suppose the right approach to the API change would be to remove the
`Scope` type completely from public API and remove the `Scope` argument
from the `Element.dependencies()` public API.
If other scopes are still required for internal pipeline traversals, we
could have an internal API which continues to support the `Scope`
argument.
> > * The mutability of public data would no longer be a concern in
> > this regard, however I would still prefer to remove this
> > mutability in order to avoid plugins composing any complicated
> > data structures dynamically which might not be stable and might
> > affect reverse dependency builds in non-deterministic ways.
>
> If I remember correctly, the original motivation to support mutable
> public data was the `dpkg_build` element plugin. Is this something we
> don't need/want to support or is an alternative solution available for
> such plugins? I don't currently have a strong opinion on this point,
> though.
This part should probably be a separate activity, but I'll outline this
here since it's fairly simple to address.
The dpkg build and deploy elements would require a small redesign, as
there are two main use cases which are currently *both* addressed using
the public data.
(A) The automated case where a dpkg_deploy element is going to
package the output of a dpkg_build element.
In this case, I would propose that dpkg_build creates the
necessary metadata in the artifact itself, perhaps in a
"/DEBIAN" or "/DEBIAN-%{element-name}" directory.
(B) The case where a user wants to build a debian package using the
output of other elements.
In this case the user did not use debian build tooling to build
the binaries, libraries etc, but just wants to package some built
software into a debian package.
Here I would propose that the user continue to fill in the blanks
themselves using public data.
The dpkg_deploy element in this case could first check if there is
public data and use that for the debian packaging metadata input, or
otherwise check if there is a "/DEBIAN" directory staged to provide
this data.
Alternatively to the above, the user could also provide a Source which
stages the packaging metadata in a DEBIAN directory, this might be more
powerful for the user to interact with debian packaging tools, but
might be seen as less convenient than specifying these details in
public data.
> > [...]
> >
> > Therefore, I currently lean towards solution 2, and changing things
> > such that runtime dependencies become completely invisible to Element
> > implementations if that is possible.
>
> I agree. I'd like the distinction between build and runtime
> dependencies to be as clear as possible. If an element affects the
> build of another element in any way, the former should be a build (or
> build+runtime) dependency of the latter, either direct or indirect
> (e.g. runtime dependency of a build dependency).
Alright, lets give a small pause for others to ring in but I think
we're mostly in agreement at this time that we can change things to say
that:
"A runtime-only dependency is not able to affect the cache key
of the depending element in any way."
Only dependencies which are in the build scope will be visible to an
Element implementation, effectively enforcing the above.
As a side effect directly related to this proposal, only direct build
dependencies (or build + runtime dependencies), will be eligible for
custom "config" dictionary parsing by depending elements.
Cheers,
-Tristan
