Templates not found on Fedora Linux about rebar3 HOT 4 OPEN

That's interesting. Generally if Rebar3 is installed as an escript, it is bundled with its own templates and they aren't set anywhere on disk. What does rebar3 point to? We do have a functionality called with rebar3 local install where Rebar3 unbundles itself on disk, and I can imagine being what is used here.

If so, calling rebar3 shell should be able to provide the data we need:

 → rebar3 shell
===> Verifying dependencies...
Erlang/OTP 26 [erts-14.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] [dtrace]

Eshell V14.0 (press Ctrl+G to abort, type help(). for help)
1> code:priv_dir(rebar).
"/Users/ferd/.cache/rebar3/vsns/3.22.1+build.5307.ref393c7cb4/lib/rebar/priv"
2> ls("/Users/ferd/.cache/rebar3/vsns/3.22.1+build.5307.ref393c7cb4/lib/rebar/priv/templates").
LICENSE.md               Makefile                 README.md
app.erl                  app.template             app_rebar.config
cmake.template           escript.template         escript_README.md
escript_mod.erl          escript_rebar.config     gitignore
lib.template             mod.erl                  otp_app.app.src
otp_lib.app.src          plugin.erl               plugin.template
plugin_README.md         provider.erl             rebar.config
release.template         relx_rebar.config        sup.erl
sys.config               umbrella.template        vm.args

The issue is possibly that if it's running as the local install mode, there may or may not be a distinct priv_dir path for the install that doesn't line up with what is packaged. If rebar3 is running as an escript it should have its own content, fetching it is a bit weirder as it involves scanning a set of virtual file paths that should always be there.

We look in code:priv_dir(rebar)++"/templates" for any local install mode for the built-in scripts.

As a work-around otherwise, there's also a path in $HOME/.config/rebar3/templates/ that allows people to define custom templates; moving the files there should also auto-repair that stuff by substituting built-in plugins with custom ones.

from rebar3.

Here's some outputs from those commands (running them as sudo yields the exact same results):

[~]$ whereis rebar3
rebar3: /usr/bin/rebar3 /usr/share/man/man1/rebar3.1.gz
[~]$ rebar3 local install
===> Uncaught error in rebar_core. Run with DIAGNOSTIC=1 to see stacktrace or consult rebar3.crashdump
===> When submitting a bug report, please include the output of `rebar3 report "your command"`
[~]$ rebar3 shell
===> Verifying dependencies...
Erlang/OTP 25 [erts-13.2.2.3] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Eshell V13.2.2.3  (abort with ^G)
1> code:priv_dir(rebar).
{error,bad_name}

For now, mkdir ~/.config/rebar3 && cp /usr/share/erlang/lib/rebar3-3.18.0/priv/templates ~/.config/rebar3/ fixes it on my end (thank you!), though like you said, that's kind of a hackjob approach. Let me know what other information I can provide!

from rebar3.

yeah, the fact that 'rebar' doesn't exist is weird, I don't know how Fedora packed the lib, but it seems to be a custom job that is neither the escript nor the release mode.

Digging into https://src.fedoraproject.org/rpms/erlang-rebar3/blob/bb89b500e3e27c601dfa5f0d339328ddcc714c2f/f/erlang-rebar3.spec they seem to build the files themselves and put them in a directory, copy the priv dir like any other app. Because they ignore the escript (https://src.fedoraproject.org/rpms/erlang-rebar3/blob/bb89b500e3e27c601dfa5f0d339328ddcc714c2f/f/erlang-rebar3-0001-Skip-deps.patch#_31) and just call the executable right away (https://src.fedoraproject.org/rpms/erlang-rebar3/blob/bb89b500e3e27c601dfa5f0d339328ddcc714c2f/f/rebar3.escript), I think they never properly set the ERL_LIBS variable in a way where rebar3 is found as an app with the priv files available. This may have to do with us not necessarily fully starting the app in that specific context.

This is, as a TL:DR; a non-standard patched up install doing things we didn't foresee. I think the workaround is the right thing in the short term.

from rebar3.

Unfortunately this has been brought up as a bug for the Fedora project more than once without the maintainer fully addressing it.

I actually symlinked the two directories, but I think you're right @ferd that this is the fix we have for now. Thanks.

from rebar3.