Templates not found on Fedora Linux

[pgattic]

Report

Rebar3 report
 version 3.22.0
 generated at 2023-09-26T04:07:17+00:00
=================
Please submit this along with your issue at https://github.com/erlang/rebar3/issues (and feel free to edit out private information, if any)
-----------------
Task: rebar3
Entered as:
  rebar3 new lib test
-----------------
Operating System: x86_64-redhat-linux-gnu
ERTS: Erlang/OTP 25 [erts-13.2.2.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit:ns]
Root Directory: /usr/lib64/erlang
Library directory: /usr/lib64/erlang/lib
-----------------
Loaded Applications:
bbmustache: 1.12.2
certifi: 2.9.0
cf: 0.0.0
common_test: 1.24.0.1
compiler: 8.2.6.3
crypto: 5.1.4.1
cth_readable: 1.5.1
dialyzer: 5.0.5
edoc: 1.2
erlware_commons: 1.6.0
eunit: 2.8.2
eunit_formatters: 0.0.0
getopt: 1.0.2
hex_core: 0.7.1
inets: 8.3.1.2
kernel: 8.5.4.2
providers: 0.0.0
public_key: 1.13.3.1
relx: 0.0.0
sasl: 4.2
snmp: 5.13.5
stdlib: 4.3.1.2
syntax_tools: 3.0.1
tools: 3.5.3

-----------------
Escript path: /usr/bin/rebar3
Providers:
  app_discovery as clean compile compile cover ct deps dialyzer do edoc escriptize eunit get-deps help install install_deps list lock new path pkgs release relup report repos shell state tar tree unlock update upgrade upgrade upgrade vendor version xref

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!

[ferd]

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.

[pgattic]

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!

[ferd]

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.

[spacez320]

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.