rebar3 compile stuck at "Fetching rebar3_gpb_plugin v2.23.2" on Windows CMD

[davidhenrygao]

When I use rebar3 complie my erlang project in CMD, it will stuck at "Fetching rebar3_gpb_plugin v2.23.2";
But in Git Bash, there is no problem.
Why? I have no idea to fix it.

My environment:

• Windows 10 Enterprise LTSC
• Erlang and rebar3 version(the latest)

rebar3 --version
rebar 3.26.0+build.5511.ref4277af3d on Erlang/OTP 28 Erts 16.2

I install Eralng use "otp_win64_28.3.exe".
I git clone rebar3 repository on Github，and run on Git Bash：

$ git clone https://github.com/erlang/rebar3.git
$ cd rebar3
$ ./bootstrap

$mkdir -p ~/.cache/rebar3/bin
$cp -f rebar3 rebar3.cmd rebar3.ps1 ~/.cache/rebar3/bin

And add ~/.cache/rebar3/bin to system environment Path.

[tsloughter]

What does the dependency listing look like? As in, is it a git dependency or a hex package?

[davidhenrygao]

What does the dependency listing look like? As in, is it a git dependency or a hex package?

@tsloughter

All dependdency fetch from hex.pm.The dependency list probably isn't the issue.

The problem is likely a compatibility issue between rebar3 and Erlang OTP 28. After I downgraded Erlang to OTP 27, the problem was resolved.

(By the way, there is no problem when use rebar3 compile with Erlang OTP 28 in Windows Git Bash! It's quite strange!)

This might be an issue of Erlang OTP 28. Maybe I should submit an issue there to check.

Thanks!

[zseronc]

I think this is a Windows temp-dir detection bug rather than a fetch/download bug.

Repro symptoms:

• rebar3 3.26.0
• Windows
• OTP 27: OK
• OTP 28: hangs with the last visible line being Fetching rebar3_gpb_plugin v2.23.2

What I observed locally is that the plugin was already fetched/cached, and the process later hung when rebar3 tried to move the temporary checkout on Windows. So the Fetching ... line is misleading here because it is just the last thing printed.

Probable cause:
rebar_file_utils:system_tmpdir/1 appears to detect Windows by checking whether:

erlang:system_info(system_architecture) =:= "win32"

If that does not match, it falls back to:

os:getenv("TMPDIR", "/tmp")

On my systems:

• OTP 27 returns system_architecture = "win32"
• OTP 28 returns system_architecture = "x86_64-pc-windows"

That means OTP 28 no longer takes the Windows temp-dir branch, and rebar3 can incorrectly choose /tmp on Windows. Later, when rebar3 invokes robocopy to move the checkout, that path becomes something like \\tmp\\..., and that step can hang.

Why OTP 27 worked and OTP 28 broke:
same rebar3 version, different system_architecture value, so the exact-string Windows detection stops working.

Workaround:
set TMPDIR explicitly to a valid Windows temp path before running rebar3.

For example in rebar3.cmd:

if not defined TMPDIR (
    if defined TEMP (
        set "TMPDIR=%TEMP%"
    ) else if defined TMP (
        set "TMPDIR=%TMP%"
    )
)