gtristan commented on PR #1898: URL: https://github.com/apache/buildstream/pull/1898#issuecomment-1999579530
> It does seem a bit odd to me to have the `projects` section that is completely ignored if the project is not the top-level project. This violates the principle of least surprise to me as I wouldn't expect a (mirror) behavior difference between operating directly on a project and operating e.g. via a tiny wrapper project that doesn't override anything. If I understand correctly, this patch is trying to selectively apply project declared mirrors onto specific subprojects... this is something I was _hoping_ to avoid with a catch all _"override all the mirrors"_ kind of statement (although I accept that at implementation time it may not be possible). If we _must_ target specific subprojects, we should do so by matching junction paths rather than project names, as multiple versions of the same project may exist in a tree/graph of loaded projects, with different aliases to resolve in those different versions. I think that @juergbi's concern of the principal of least surprise could be addressed simply by naming the key something like `subprojects`. > As aliases are generally project-specific, we can't simply apply a project's mirror config to its subprojects. However, could it make sense to support specifying an alias mapping in junctions? I.e., map aliases of the subproject to aliases of the current project (not URLs). And then the mirror configuration of the current project could be applied incl. mirror plugins. An interesting aspect of this would be that this could work recursively and avoid the behavior difference mentioned above. > > A possible alternative to specifying a mapping for each alias in the subproject would be to specify an alias prefix. This is an interesting alternative, as it allows overriding subproject aliases and mirrors in cases where a custom `SourceMirror` plugin is not needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
