<div dir="ltr"><div>While this is true, we also typically recommend not deploying from the shell, and until earlier this year had a very visible warning always displayed advising people not to do that. The rebar3 shell is meant for development first and foremost, and has default configured options that are convenient for rebar3 but may not fit your application and that you may not want to marry yourself to in the long run.<br></div><div><br></div><div>If you want to see `rebar3 new release my_app`, you will get everything required in the configuration file and structure to call 'rebar3 release' and generate the release you can boot with a single script whose path is output at the end of the command.</div><div><br></div><div>Regards,</div><div>Fred.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 24, 2020 at 10:38 AM Roger Lipscombe <<a href="mailto:roger@differentpla.net">roger@differentpla.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 24 Nov 2020 at 14:27, Jesper Louis Andersen<br>
<<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>> wrote:<br>
> The right way of solving this is to start using applications. An application has a top-level supervisor which is then handled by the application manager in the system, and thus not being shut down as long as the VM is running. It's a bit of a curve-ball I'm throwing you, I'm afraid. Applications are far more involved to set up<br>
<br>
I agree that applications are the way to go. I disagree that you need<br>
all of the extra release baggage, at least at the start.<br>
<br>
$ rebar3 new app my_app<br>
$ cd my_app<br>
(...create your gen_server and add it to my_app_sup...)<br>
$ rebar3 shell<br>
<br>
Done. You can look at how to do releases later.<br>
</blockquote></div>