rebar3 woes about evm

[robisonsantos]

Can you provide a minimum reproducible code? It is unlikely I will be able to do anything if the problem is incompatibility between versions, but if this is just an erlang compilation issue (maybe missing some flags) I can try to fix it

…

On Mon, May 29, 2023 at 10:41 AM ericb-summit ***@***.***> wrote: I realize this is not directly evm problem, but just asking if there's some way to kill 2 birds with one stone here. It looks like something changed in > erl23 and a rebar3 compiled with sayl, er23 barfs when run against erl25 with init terminating in do_boot ({undef,[{rebar3,main,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}) This requires recompiling rebar3 when switching with evm. What would be the cleanest way to leverage how evm works such that switching evm would also switch rebar3 version? I can do the work and send a PR. Thanks. — Reply to this email directly, view it on GitHub <#47>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA66LLOW6NH4BVXCUJZKWTXISRRRANCNFSM6AAAAAAYS2COZQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Robison W R Santos

[ericb-summit]

Sorry let me be sure I explained properly:

Let's say I evm use 23.3.4.18, and install rebar3 from sources, which is just ./bootstrap && ./rebar3 local install which pops it into ~/.cache/rebar3/bin/rebar3. Of course rebar3 works fine at this point.

Now if I, say evm use 25.3.2, rebar3 won't work, due to some incompatibility between the compiled rebar3 and erl/otp 25.3.2. So, I have to rebuild it, git clean -dffx && ./bootstrap && ./rebar3 local install and this newly compiled rebar3 will work on 25.3.2.

But then going back to evm use 23.3.4.18 I would have to recompile rebar3 again.

So my question was, in a way: is there some place I could put the version-specific rebar3 so a specific rebar3 would follow evm use xxx ? Would it be okay if we simply placed rebar3 for example in ~/.evm/erlang_versions/otp_src_25.3.2/bin/erl for 25.3.2 and similarly for other versions?

[robisonsantos]

In theory yes, but I don't know exactly how rebar and the Erlang compiler get "linked" after the rebar installation. We would need to understand how Erlang finds the installed binaries to use and select the "right" versions depending on the selected version of Erlang.

…

On Mon, May 29, 2023, 11:30 PM ericb-summit ***@***.***> wrote: Sorry let me be sure I explained properly: Let's say I evm use 23.3.4.18, and install rebar3 from sources, which is just ./bootstrap && ./rebar3 local install which pops it into ~/.cache/rebar3/bin/rebar3. Of course rebar3 works fine at this point. Now if I, say evm use 25.3.2, rebar3 won't work, due to some incompatibility between the compiled rebar3 and erl/otp 25.3.2. So, I have to rebuild it, git clean -dffx && ./bootstrap && ./rebar3 local install and this newly compiled rebar3 will work on 25.3.2. But then going back to evm use 23.3.4.18 I would have to recompile rebar3 again. So my question was, in a way: is there some place I could put the version-specific rebar3 so a specific rebar3 would follow evm use xxx ? Would it be okay if we simply placed rebar3 for example in ~/.evm/erlang_versions/otp_src_25.3.2/bin/erl for 25.3.2 and similarly for other versions? — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA66LJCAQT6NMV6OY3FTHDXIVLVFANCNFSM6AAAAAAYS2COZQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ericb-summit]

This is what installed rebar3 looks like

#!/usr/bin/env sh
## Rebar3 3.22.0+build.5277.ref44d0587a
REBAR3_VSN=${REBAR3_VSN:-3.22.0+build.5277.ref44d0587a}
erl -pz /home/enry/.cache/rebar3/vsns/${REBAR3_VSN}/lib/*/ebin +sbtu +A1 -noshell -boot start_clean -s rebar3 main $REBAR3_ERL_ARGS -extra "$@"

Within that .cache/rebar3/.. folder are beam files kind of like an installed erlang release. That complicates things a bit. I think I might reach out to ferd to get his input on this.

[robisonsantos]

If we can make rebar install in different folders and then, somehow, manipulate the path whenever we use a different version of Erlang, then that problem would go away. For that we would need to either manage rebar installation via evm or install rebar where we want it to be manually. We would need to teach evm to load rebar anyways, so probably the first option is better. Problem is, I don't think I have the bandwidth to do this in the time you might need it.

…

On Tue, May 30, 2023, 8:59 AM ericb-summit ***@***.***> wrote: This is what installed rebar3 looks like #!/usr/bin/env sh ## Rebar3 3.22.0+build.5277.ref44d0587a REBAR3_VSN=${REBAR3_VSN:-3.22.0+build.5277.ref44d0587a} erl -pz /home/enry/.cache/rebar3/vsns/${REBAR3_VSN}/lib/*/ebin +sbtu +A1 -noshell -boot start_clean -s rebar3 main $REBAR3_ERL_ARGS -extra "$@" Within that .cache/rebar3/.. folder are beam files kind of like an installed erlang release. That complicates things a bit. I think I might reach out to ferd to get his input on this. — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA66LIOYL4W7XMG6MRJHT3XIXOINANCNFSM6AAAAAAYS2COZQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ericb-summit]

Ok so turns out rebar3 is by design friendly to current +2 versions of erlang.

So:

• Compile for 23, use on 24, 25 (I got my example above mixed up)
• Compile for 25, won't work on 23, or 24 (this is what I meant to write above), only works on 25,26,27

I can live with with current + 2 version it's a fair limitation. We can close this.