Re: [BuildStream] Changing element files extension requirements

[Phillip Smyth <phillip smyth codethink co uk>]

Hey Tristan,

Thanks for replying, I just had a couple of follow up questions.

On Wed, Nov 14, 2018 at 06:16:09PM +0900, Tristan Van Berkom wrote:
> Hi Phillip,
>
> Thanks for bringing this up !
>
> On Mon, 2018-11-12 at 16:54 +0000, Phillip Smyth via BuildStream-list wrote:
> > Hi all,
> >
> > Following on from a discussion on #buildstream on IRC, there have been 
> > suggestions of making file extension like `*.bst` mandatory.
> >
> > This would currently be of use with the introduction of build all and 
> > show all commands, as currently it is difficult to know if a file is an 
> > element or some other kind of file,
>
> Yes, it will be unavoidable; the only alternative I could see is to
> alternatively have a sort of mime-type expression in the beginning of
> the file content, but this is more expensive both in terms of
> processing and in terms of the burden of writing .bst files.
Where would be a good place to put this check, and how should we enforce it?
A simple option seems to be to put a check in the buildstream/_frontend/cli.py
Which would check the end of the `elements` variable for ".bst"
and return an error + message if it's not found.
> >  and the current proposed solution 
> > isn't fool-proof as it assumes that only element files will exist inside 
> > of the element-path directory, which may not be the case, and in some 
> > instances, the element-path directory does not exist.
>
> I don't see any issue with this.
>
> If elements are outside of the element-path, then they are not
> accessible in any way, and should not be included in any `--all`
> commands, they just dont exist.
>
> If the element-path directory is specified in project.conf and does not
> exist, then it is a project that has no elements at all.
In regards to the build all functionality,
how would you suggest we deal with projects that use junctions?
As these would seem to cause issues.

> > One suggestion was to introduce a "element-extensions:" config which 
> > could be used to specify elements, however there is the issue of a 
> > default value being required, and leaving the default as blank or "*", 
> > would result in this providing no guarantees of consistency.
>
> I think this is a bad idea.
>
> If we allow configurability, we risk that people will use that
> configurability.
>
> This means that the cognitive effort for approaching a new project is
> increased, which is a bad idea. The convention is `.bst` across the
> board right now, and I am not seeing projects which break this,
> enforcing it will not be immensely painful.
>
> Further, in a very general sense; it is *never* desirable to make
> anything configurable until the very last minute; when users present
> cases that they have a real pain point which can be helped with a
> configuration option, then we should expose one; but we should not
> increase our configuration API surface until we know it is really
> needed or obviously useful.
>
> Cheers,
>     -Tristan
Thanks,
Phillip Smyth (Nexus)

-- 
Phillip Smyth, Software Engineer                           Codethink Ltd
Telephone: +44 7762 840 414        3rd Floor, Dale House, 35 Dale Street
https://www.codethink.co.uk/          Manchester, M1 2HF, United Kingdom
We respect your privacy.    See https://www.codethink.co.uk/privacy.html