Open pgattic opened 11 months ago
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.
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!
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.
Report
Current behavior
I attempted to create a new Erlang library using the "lib" template; however, rebar3 claims that I don't have such templates. When typing
rebar3 new lib test
for example, the result I get is===> Template 'lib' not found.
It seems that my computer indeed has all the templates, which located in /usr/share/erlang/lib/rebar3-3.18.0/priv/templates, yet it can't use them to generate new projects. I seem to get a similar error for the rest of the templates.Expected behavior
I expected it to initialize a new project with the specified template.
I am on Fedora 38, and I tested it independently on two different installs, both of the KDE Spin. I installed rebar3 through the erlang-rebar3 package. Am I just misinformed, or was that supposed to be one of the ways to create new projects?
Let me know what else I can do, or what information I can provide!