Any way to disable the symlinking of _build\prod\plugins to _build/default/plugins?

[fcbry]

I'm coming from the Dagger -> Docker -> Elixir -> Hex -> Rebar3 direction, so forgive me if I'm looking in the right place.

https://www.rebar3.org/docs/basic_usage/

It seem there is a behavior of symlinking the _build\prod\plugins\<plugin> to _build\default\plugins\<plugin>

In my case: File: 'C:\code\fcbry_teamwork_poc\code\deps\redbug\_build\prod\plugins\hex_core' -> 'c:/code/fcbry_teamwork_poc/code/deps/redbug/_build/default/plugins/hex_core'

Unfortunately, this is playing badly with dagger/dagger/issues/8545 / the golang archiver package. I mean it's an edge case with probably one user of the Windows 11, Docker, Dagger, Rebar3 stack on the planet.

Anyhow, assuming it'll take a year for Dagger to fix, other than removing the rexbug dependency from my project is there any other way to prevent the symbolic linking behaviour?

[ferd]

This is a general optimization to allow dependencies and plugins with identical content to not be rebuilt for every subcommand.

Undoing this would be likely to make things incredibly slower for most users as any first test run would likely need to rebuild all deps and plugins, and be re-done every time the profiles change.

We do OS-specific checks for this (see

rebar3/apps/rebar/src/rebar_file_utils.erl

Lines 111 to 154 in 29ccddb

	symlink_or_copy(Source, Target) ->
	Link = case os:type() of
	{win32, _} ->
	Source;
	_ ->
	rebar_dir:make_relative_path(Source, Target)
	end,
	case file:make_symlink(Link, Target) of
	ok ->
	ok;
	{error, eexist} ->
	exists;
	{error, _} ->
	case os:type() of
	{win32, _} ->
	S = unicode:characters_to_list(Source),
	T = unicode:characters_to_list(Target),
	case filelib:is_dir(S) of
	true ->
	win32_symlink_or_copy(S, T);
	false ->
	cp_r([S], T)
	end;
	_ ->
	case filelib:is_dir(Target) of
	true ->
	ok;
	false ->
	cp_r([Source], Target)
	end
	end
	end.
	%% @private Compatibility function for windows
	win32_symlink_or_copy(Source, Target) ->
	Res = rebar_utils:sh(
	?FMT("cmd /c mklink /j \"~ts\" \"~ts\"",
	[rebar_utils:escape_double_quotes(filename:nativename(Target)),
	rebar_utils:escape_double_quotes(filename:nativename(Source))]),
	[{use_stdout, false}, return_on_error]),
	case win32_mklink_ok(Res, Target) of
	true -> ok;
	false -> cp_r_win32(Source, drop_last_dir_from_path(Target), [])
	end.

) and depend on trying with file:make_symlink/2 to detect whether this is workable.

I think it's possible to disable symbolic links in windows by removing permissions from a user, but I don't know of anyway of removing that ability from a non-windows setup.

Other ways I could imagine:

1. edit rebar3 code to make a one-time switch that disables usage of symlinks altogether when someone passes in an environment variable (self-contained, but bad idea, maybe)
2. make a weird hook that can detect this happening and replaces the symlink with a copy (it is very rebar3-specific, so doing this could depend on how the sequence of calls is set up in your repo)

To think about option 2), I'd need to know how the whole thing is set up to see if anything makes sense. Falling back to 1) could happen, but it's a really weird workaround for us to carry around and expose.

[fcbry]

Thanks FredFerd - I've decided to take the path of least resistance and just vendor in the redbug code into rexbug repository.

https://github.com/nietaki/rexbug/compare/master...fcbry:rexbug:workaround/vendor-redbug?expand=1

I think this is going to bite anyone who starts using Dagger project to build Elixir projects if:

1. They have rebar3 dependencies (transitive or otherwise).. and..
2. They are using the esoteric windows docker combination

For the majority of users it won't even be an issue on windows as they can add deps folder to .dockerignore as is best practice anyway.

Thanks, and have a nice day. B

[ferd]

We've also had issues in the past with some windows things when using virtual machines. There are bugs there with some combinations of filesystems particularly when one is shared across the OS and the VM, I wouldn't be surprised if you hit something similar. Never could figure out, and I no longer have a workable Windows computer.

[fcbry]

Thanks Ferd, yes it's only an issue for Dagger.io as it seems they upload the entire root directory into the docker server (archive, then unpack), and it (the golang archive library) doesn't grok the symlinks.

(Dagger.io could probably just handle those null files and print warnings if they were bothered).

It won't affect regular docker build users as they will .dockerignore the deps directory (keyed to mix.exs/mix.lock) in order to maximise the docker cache hits. Anyhow I've worked around it for my use case, thanks for looking into it. B