Re: [BuildStream] Changing element files extension requirements

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

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.

>  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.

> 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