Hello Tristan, everyone, I've read the proposal and while I think it is okay, it doesn't cover everything needed by the "putting tarballs in gitlab using git-lfs" usecase. For that usecase, we have an additional requirement which is authentication. Right now, the plugins that download a single file only support basic http authentication using .netrc, which isn't enough for gitlab. Maybe that should be a different issue that needs to be handled separately, but the fact that which authentication method to use depends on the host, and the host can be changed by the mirror plugin makes me think they might be related.
I have a few comments inline on the proposal. Le mer. 20 sept. 2023 à 06:57, Tristan van Berkom <[email protected]> a écrit : [...] > def translate_url( > self, > url: str, > project_name: str, > alias_name: str, > alias_url: Optional[str], > ) -> Optional[str] Maybe this is out of scope for this, but would it be possible to differentiate between git and "raw file" urls in this new api? It would require cooperation from the source plugins, but I think it's reasonable to do it in a new API. [...] > Since this proposal does not provide for using SourceMirror plugins in > user configuration, I propose we a new value here: > > o toplevel-mirrors: Only allow fetching from mirrors defined in the > toplevel project configuration I think this is useful regardless, but given that we can't currently define mirrors for junctions it wouldn't be very useful. Another thing: would this cover mirrors in the user configuration or only toplevel project configuration? The former would slot-in nicely between mirrors and user, but the latter would be more restricted than user. [...] > Supporting plugin loading in buildstream.conf without a supporting > project would be very awkward and I don't think this is a worthwhile > endeavor. I think it might be reasonable to support plugins from pip origin only, but I agree that it's not really necessary. Regards, Abderrahim
