Re: [BuildStream] Proposal: Allowing download-only sources to work on local files

[William Salmon <will salmon codethink co uk>]

On 02/12/2019 14:13, Tristan Daniël Maat via buildstream-list wrote:
[...]
> > > - All source plugins which operate on files are unified as subclasses of
> > >    a single base class, say FileBasedSource
> > > - This base class handles the 'url' and 'ref' keys of the source config
> > > - First it checks whether 'url' is a fully-qualified URL or is just a
> > >    relative path. If it's the former, it is fetched as necessary and
> > >    stored in the source cache
> > > - If the URL is a relative path, specifying a ref is optional. If it is
> > >    given and is different from what is calculated, an error is throw
> >
> > This seems like the path of smallest disruption to existing users I 
> > would be tempted by not letting local
> > not have a ref unless specified in project.conf but dose that sound 
> > too disruptive to others?
>
> Unlike Will I'm not too happy about this, we'd need to classify whether 
> a path is a URI or a relative path.
>
> This is difficult, because a URI could be a perfectly valid path name, 
> albeit a rather horrible one. While
> this isn't the most realistic use case, I'd much rather see a way to 
> have both a `url` and `path`, as described
> for `remote` and `local` sources, simply to stay far away from using 
> heuristics to decide anything - it
> feels wrong to have this ambiguity when we want precise definitions of 
> inputs.
>
> The simplest way to implement this would be to have an implementation 
> for a new `path` key which
> simply performs the old operation, except with 
> `file:///path-to-project/<path>` to prevent any disruption.

Are you suggesting that we leave url as is and add a mutually exclusive 
key 'path'. Were a plugin using path is allowed to have a predefined ref 
and if not then it hashes the file?

As mentioned I am happy with this option too.

Will