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= "" 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.