I've collected your comments in an org-file so that it's easier (at least for me, but I hope it's the case for you too) to follow multiple discussions at the same time. I've only included the ones that are still open to discussion. The structure should be self-evident. The most important comment may be Comment 9. Cheers. * TODO Comment 4 ** LMP This reeks of the hack that we need for cargo-build-system, except with a worse variable name. I strongly suggest looking into ways we can do without it. ** PHF This idea came from a discussion with jpoiret. See: https://logs.guix.gnu.org/guix/2023-10-24.log#180111. It seems that the idea you suggest is to use =search-path-as-list= as hinted below (=Comment 9=). Is this correct? * TODO Comment 6 ** LMP Uhm, how are you improving the status quo here? ** PHF Comment updated with: #+begin_example ;; If these directories exist, then no error occurs. So, we make sure ;; they exist. #+end_example Is this OK? I don't see how to prevent rebar3 to do that. It's apparently an opened issue: https://github.com/erlang/rebar3/issues/1173 * TODO Comment 9 ** LMP You might want to look into possible PATH variables or put these sources into a special folder so that you can use search-path-as-list. ** PHF Perhaps an idea: 1) If we require all Erlang packages to have an output “src” something like: /gnu/store/…elixir-pkg-1.2.3/src/elixir/src/…, 2) then (search-path-as-list '("src/elixir/src") '("/gnu/store…elixir-pkg-1.2.3" …)) would return '("/gnu/store…elixir-pkg-1.2.3/src/elixir/src" …) ≡ lst-src. 3) Given lst-src, it would be enough to install each source under _checkouts, i.e., _checkouts/lib-name/src. It is probably feasible to retrieve lib-name from somewhere. What do you think? ** LMP Rather than require, you can add a phase to ensure that this is the case. I'm not sure whether we should make that an extra output, however; there might be many packages for which we don't need those sources and where we do need them, we could potentially add them as native-inputs. ** PHF Agreed. ** LMP Another alternative would be to keep the sources in =lib/erlang/lib/lib-name/src= so that it gets symlinked by the phase we have. Though at that point we can surely go with a less surprising install directory. ** PHF Here is the approach taken so far: 1) The objective is to ensure that =mix compile= does not attempt to use the network and, as a result, fails to compile. 2) For the above to be true, it is necessary to have — at build time — the sources of all Erlang input packages and install them as checkouts. 3) Thus, the question becomes: How to access all the Erlang package sources at build time? 4) One idea was to have the client side of the build code send all the sources to the server through the poorly named argument =#:sources-erlang=. This led to the current code. It relies on the fact that for a given Erlang package, it is possible to access its source in the store, for example, =/gnu/store/…erlang-kv/erlang-kv.tar=. 5) Instead, you propose modifying the installation process so that sources are installed along with the built libraries. The source might be collected with =search-path-as-list=. The downside seems to be that the source code is stored twice: first in the archive, then in the package. However, this could lead to a much cleaner method of passing the sources to the build-side code, that is, the source code would not be passed through =arguments=. I'm sending a patch based on this latter idea. Are you OK with that? * TODO Comment 10 ** LMP Also, IIUC, erlang-depends already does something rather similar. Is there any reason it's broken for you? ** PHF Without that (i.e., _checkouts/lib-name/src), rebar3 will not compile things. Is this a satisfying explanation? ** LMP I mean, ideally we would store these things in some other directory, given that _checkouts/lib-name already contains the precompiled stuff after erlang-depends. However, if the tooling insists on storing both in the same place, you could simply amend the existing erlang-depends phase to: 1. Copy instead of symlinking 2. Also copy the sources ** PHF If I understand correctly, this should be addressed with the patch from =Comment 9= section above.