This is more Erlang-related question than Elixir. On one hand having a path to some directory in let’s say environment variable is good idea. Elixir on its own is flexible and does not force much things like many languages/frameworks. However it’s based on Erlang and this is a bit different story.

Returns the path to the priv directory in an application. Equivalent to code:lib_dir(Name, priv)

Source: https://www.erlang.org/doc/man/code#priv_dir-1

Returns the path to a subdirectory directly under the top directory of an application. Normally the subdirectories reside under the top directory for the application, but when applications at least partly reside in an archive, the situation is different. Some of the subdirectories can reside as regular directories while others reside in an archive file. It is not checked whether this directory exists.

Source: https://www.erlang.org/doc/man/code#lib_dir-2

Both lib_dir and priv_dir functions are essential in Erlang and trying to changing priv path may cause unexpected problems. Also priv files are usually packages into release, so even if it would be in different directory on dev/build machine then you would need to alter the packaging logic, so the files would be extracted in another location on prod machine.

Other solutions may also have their own downsides. Symbolic links may work without any problem or be not supported at all. The biggest problem here would be for example an existing symbolic link to not existing path. Creating directory would not work as same as without symlink.

Also have in mind that in priv directory there could be much more files than just assets. Trying to change priv location at least in long term perspective seems not worth the effort.

However that’s not all options we have, right? Elixir is flexible, so let’s try find something on Elixir side that works better in your use case … I would go in a bit different way of thinking. I see 2 options:

1. Add a code which at runtime, right after application starts, changes some configuration files. That should be simple to do and this way other applications do not need to worry about paths as all of them could simply fetch a value of environment variable.

2. Plug.Static-based solution - if assets are all you need then you should be fine with the plug’s flexibility.

• :from - the file system path to read static assets from. It can be either: a string containing a file system path, an atom representing the application name (where assets will be served from priv/static), a tuple containing the application name and the directory to serve assets from (besides priv/static), or an MFA tuple.

Source: https://hexdocs.pm/plug/Plug.Static.html

This way allows not only to specify a different location for each environment, but also it’s easy to add checks and fall back just in case something bad would happen. That’s said … since it happens on runtime it could (but not need) to increase a response time …

plug Plug.Static, from: {MyApp.ModuleName, :func_name, [Mix.env()])

# …

def func_name(env) when env in ~w[dev test]a do
  # path on dev and CI machines
  :my_app
  |> :code.priv_dir()
  |> Path.join("static")
end

def func_name(_env) do
  # for example fetch an environment variable
  prod_path = get_prod_path()

  if File.exists?(prod_path) do
    # prod-only path
    prod_path
  else
    # fallback
    func_name(:dev)
  end
end