Variables in snapcraft.yaml?

[Dan Kegel]

I should think a simple general variable expansion in all string
values would suffice for my use case.

More complex use cases would be better served by generating the .yaml
file as I do now.

So, yes, ${release-version}, but set it via  --variable
release-version=foo rather than --release-version=foo,
and support ${joe-bob} and ${billyjoe}, or whatever variables the
author cares to define.

On Sat, Oct 15, 2016 at 3:29 PM, Leo Arias <leo.arias at canonical.com> wrote:
> On Sat, Oct 15, 2016 at 12:49 PM, Dan Kegel <dank at kegel.com> wrote:
>>
>> Thoughts?
>
>
> I would like to hear yours instead :)
>
> Take a look at [1] where we started the discussion about setting the version
> in the yaml file. It seems that we should provide at least a way to
> overwrite the version; but should we provide ways to overwrite and inject
> values to all the fields? Maybe, I'm not sure. I think we should avoid to
> make snapcraft a full templating engine. And for what I've seen, the
> projects that need to change more than the version, or some more complex
> replacing, they are already preprocessing some files before the build. In
> that case, it could be reasonable to have a snapcraft.yaml.template in the
> repository, and use sed, or the go text/template, or something like that to
> generate the yaml before calling snapcraft.
>
> We will have a session to design a solution for this during the sprint next
> week. So please let us know your preference to take it into account.
>
> pura vida.
>
> [1] https://lists.ubuntu.com/archives/snapcraft/2016-September/000907.html
>
> --
> ¡paz y baile!
> http://www.ubuntu.com