Re: [BuildStream] Proposal: Allowing downloadable file plugins to work on local files

[Tom Mewett <tom mewett codethink co uk>]

Thanks for the feedback!

On Thu, 15 Aug 2019 16:02:07 -0400
Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:

> So I wonder now, is there a reason to limit the impact of this change (1)
> to only DownloadableFileSource ?
>
> It seems to me that this pathing kind of feature fits nicely into what
> `Source.translate_url()` does, perhaps we could allow expansion to
> project relative "file://..." URIs across the board for all plugins ?

I did consider this, but without further abstracting fetch and track,
the behaviour in (2) would have to be implemented manually again. Plus,
as I say in (3), this proposal would generalise DownloadableFileSource
so it could be used with more plugins anyway. (Maybe it could be made a
public class?)

> > 2.
> > If a file: URL is given, the plugin behaviour changes to be similar to
> > that of the local source:
>
> Nit: The `local` source uses `path:` here, would probably be better to
> use the same word for consistency...

By 'file:' here I meant the URL scheme, not the config key. But I
suppose it should be considered whether 'url' is a clear name any more;
maybe 'location' ? And does this mean you're not a fan of removing
local as in (3)?

> It may be that there are cases a user would want to opt into using refs
> for local files, and it appears your proposal (1) would allow this.

It does, but only without (2). Perhaps if the ref is not given, it is
never checked or updated with track, but if it is, then the
checks/tracking occur. That would allow us to properly test ref checks,
like in test_no_ref for 'remote'.

Tom