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. > * 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. > [...] > > 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). Cheers, Jürg
