How to add extra files to umbrella release?

You should be using Application.app_dir(:app_name, "priv/dir/…") in your code to reference files in priv/ folder. You can use configuration for the second parameter if needed.

Additionally you can use the :code.priv_dir/1 function

Yeah, it’s using charlists though and is imo not as nice to work with from elixir.

Using:

  products:
    "application-data\\lib\\web_interface-#{Application.app_dir(:web_interface, "priv/")}"
    |> IO.inspect(label: "PRODUCTS"),

results in:

** (ArgumentError) unknown application: :web_interface
    (elixir 1.15.6) lib/application.ex:1010: Application.app_dir/1
    (elixir 1.15.6) lib/application.ex:1037: Application.app_dir/2
    (stdlib 5.1.1) erl_eval.erl:746: :erl_eval.do_apply/7
    (stdlib 5.1.1) erl_eval.erl:325: :erl_eval.expr/6
    (stdlib 5.1.1) eval_bits.erl:106: :eval_bits.eval_field/5
    (stdlib 5.1.1) eval_bits.erl:71: :eval_bits.expr_grp1/6
    (stdlib 5.1.1) eval_bits.erl:67: :eval_bits.expr_grp/5
    (stdlib 5.1.1) erl_eval.erl:545: :erl_eval.expr/6

If you mean however, that my application code should reference Application.app_dir(:web_interface, "priv/") then this is not possible. The applications are independent from each other. The only thing each child app requires is a path to a folder with assets.

I cannot tie any child app to another app by mentioning the other app’s name in the code. This is not a solution I can implement, which is why I am trying to understand what can be done at the level of releases or prod.exs files.

Same applies for :code.priv_dir.

You can configure e.g. {:app_name, rel_path} and transform that to Application.app_dir/2 calls at runtime. That’s e.g. how Plug.Static is to be configured.

So, instead of:

 products:
    "application-data\\lib\\web_interface-#{Application.app_dir(:web_interface, "priv/")}"
    |> IO.inspect(label: "PRODUCTS"),

I would have:

 products:
    {:web_interface, "priv/..."}",

And then in the code instead of having:

@products_file compile_env!(:my_app, :products)

#....

case File.read(products_file) do 
  # ...
end

I would instead have:

@products_file compile_env!(:my_app, :products)

#....

case products_file |>  Application.app_dir() |> File.read() do 
  # ...
end

Correct?

I can see this working.
However, would this be advised over moving the folders inside of the release tar to a new position?

That’s the way to go yes.

FWIW these days I register these release-resiliant path concerns in my application’s compile-time config.exs. I find it to be more reliable and easier to reason about if I do it myself:

# config/config.exs
import Config

root_dir = Path.expand("../..", __DIR__)
priv_dir = Path.expand(Path.join(project_root, "priv"))
assets_dir = Path.expand(Path.join(project_root, "assets"))
static_dir = Path.expand(Path.join(priv_dir, "static"))
static_assets_dir = Path.expand(Path.join(static_dir, "assets"))

config :project, :root_dir, root_dir
config :project, :priv_dir, priv_dir
config :project, :assets_dir, assets_dir
config :project, :static_dir, static_dir
config :project, :static_assets_dir, static_assets_dir

# Use variables above to configure things like `:esbuild` in this file

# Use `Application.compile_env!(:project, :static_assets_dir)`
# to configure things like `Plug.Static`

This works well for umbrella apps, since the each have their own config :app_name space.

For often-referenced paths, I’ll even add a shortcut in my project’s main entrypoint module:

# lib/project/application.ex
defmodule Project.Application do
  def app_name, do: :project
  def root_dir, do: Application.compile_env!(app_name(), :root_dir)
  def static_dir, do: Path.relative_to(Application.compile_env!(app_name(), :static_dir), root_dir())
end

Then, for example, configuring Plug.Static can look like:

# lib/project_web/endpoint.ex
plug Plug.Static,
  at: "/",
  from: {Project.Application.name(), Project.Application.static_dir()}

Tbh that feels a bit bend over backwards to start with relative paths, expand them to absolute paths for the context of the mix project, just to turn them back into relative paths within the application code again. But I do like the approach of having functions return the paths. I’ve used that approach as well in some projects. It puts a clear interface of what paths are provided by an application / which ones are used by downstream consumers.

I am generally not comfortable having functions that return configuration settings.

To me, configurations are different from the functionality an application offers, they are a prerequisite and should therefore have their own space, instead of polluting the main API that I expose to the public.

Still, if nothing else works, I will definitely use such approaches, I find code that actually does something better than code that is theoretically more perfect, but then does nothing

Also, thanks @christhekeele for your input. I appreciate you took the time to read all the threads and then took even more time to add your own opinion, even though the topic is becoming long and I had marked it as solved.