fix: dep overrides to dev template

[charmful0x]

about

testing rebar3 new device name=testdev from latest edge results in the error below because Forge device template dont inherit the root hyperbeam dependency overrides. so running rebar3 compile in /testdev:

      Dep cowlib has invalid version >= 2.16.0 and < 3.0.0

patch

added the same dep overrides to the generated device rebar.config so external dev repositories compile from a clean template

repro

• rebar3 new device name=testdev from edge fails with the cowlib error above ^
• install-template --local "$PWD" from this PR branch generate a project that compile fine
• install-template --branch fix/plugin-rebar-config --repo https://github.com/permaweb/HyperBEAM.git generates a project that compile as well

[samcamwilliams]

Awesome, thank you!

Do you think we could somehow usefully share this between the 'core' HB build and the template automatically perhaps? Then we don't have to worry about keeping it up-to-date.

Dumb v0: Just have a %%% ===== END OF SHARED ===== divider in the base rebar.config and copy the lines above it into the template config on ./local-install? Better: normal file includes, or multiple rebar.configs if r3 allows it 😁

[charmful0x]

good point @samcamwilliams , agreed! what about something like src/forge/plugin/priv/device_overrides.config containing the overrides, then in _rebar.config we add a placeholder for it?

 {overrides, [
  {{hb_device_overrides}}
  ]}.

and 'core' hyperbeam consume that fragment from rebar.config as well?

then for templates, install-template reads and render it? we endup with some sort of shared contained addresable overrrides

[samcamwilliams]

Something like that would be great, if there is nice rebar3 support for it.

and 'core' hyperbeam consume that fragment from rebar.config as well?

The issue I think is that our build invocation is through rebar3 which will load the config to start, so unless we wrapped it or provided a bootstrap rebar config that then re-invoked itself (🤮) I am not sure how we do it. Perhaps the multiconfig setup is something that r3 already supports?

[charmful0x]

then maybe one possible path can be putting the overrides in shared config file, then using rebar.config.script and have install-template render the same shared config into the generated _rebar.config (?)

https://rebar3.org/docs/configuration/config_script/