[bug#66801] [PATCH va3e5ae0f..37252e07 01/32] rebar-build-system and packages.

[Liliana Marie Prikler]

Am Montag, dem 30.10.2023 um 13:30 +0100 schrieb Pierre-Henry Fröhring:
> [...]
> 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
I'd recommend sticking with the current flow, however, and either
create those directories unconditionally or inside the 
  (when (file-exists? …) …)
In general, don't mix gratuitous "styling" changes into your commits. 
Try to keep your edits minimal and reviewable.

> 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?
> [...]
One idea both of us haven't voiced so far is to actually grab these in
the (guix build-system …) code rather than the (guix build …) side and
make the sources available via a mapping.  Think package → (package-
source package).

The downsides of this are quite obvious.  First, to my knowledge
something like that hasn't been done yet, so there's no reference
point.  Second, the (guix build …) side would still need to identify
what's an erlang source.  Given our code for the unpack phase, I'd
hazard a guess that this is non-trivial.  Thus, even if there's
theoretically a way to not store the same tarball twice, in practice it
doesn't really matter.

You could alternatively also write the sources to a special source
output if and only if one such output is requested via the outputs
field.  Again, I'd hazard a guess that this would be a very standard
output for anything that needs to go into mix-build-system and thus not
worth the split after all.

Alternatively² you could patch mix to only look for compiled stuff and
not sources.  That would tackle the issue at the root instead of trying
to work around it, with the caveat being that we would need to maintain
this patch ourselves if upstream doesn't accept it.

Cheers