IRC channel logs


back to list of logs

<rekado>this is quite ugly because changing configure flags would need to be passed to the bazel fetcher, and that leads to a different hash
<rekado>for bazel-using packages we effectively lose the ability to easily customize them
<rekado>annoyingly I still haven’t been able to convince bazel to accept the prepared tarball.
<rekado>it still insists on fetching everything from the internet
<civodul>OTOH, it wouldn’t be different if we tried to run Guix inside Nix or vice versa
<civodul>or Guix inside Guix, actually
<rekado>I had the same thought
<civodul>these tools want to control everything
<rekado>it feels all sorts of wrong to try to squeeze bazel into Guix
<rekado>it’s a little surprising that it took so long for things like bazel to appear
<civodul>how well does the Bazel model map to the functional model of Nix/Guix though?
<rekado>I guess Golang is similar in that its network-native
<rekado>I know very little about Bazel. It deals in terms of repositories and workspaces.
<rekado>It resolves and connects labels to build a DAG.
<rekado>it doesn’t seem to use content hashes for anything
<rekado>it doesn’t seem to like linking by name and instead insists on building things from source (from specific commits).
<rekado>it implements an extensible DSL, and extensions are resolved dynamically just like any other repository
<rekado>so the descriptions of the builds and how they relate to must be evaluated, and to do that may require access to the internet
<rekado>my previous attempt was to override each and every repository manually, providing a separate source code origin for each dependency
<rekado>that turned out to be a game of whack-a-mole as I couldn’t tell ahead of time just how many different repositories there are to be overriden.
<rekado>so the way Nix does it is to run “bazel build --nobuild” (beautiful illustration of the duality inherent in any decision), let it resolve all repositories and download source code as needed.
<rekado>sanitize it a little and wrap that all up, then provide it as a sort of super input for the actual build.
<rekado>I do wonder if there might be way to use bazel to generate Guix packages for each part of the build
<rekado>the difficulty here is that nodes in the Bazel DAG aren’t necessarily package artefacts
<rekado>they could just be headers or object files prior to linking
<rekado>and they just live in the Bazel cache, not in a stable location in the file system.
<civodul>“bazel build --nobuild” :-)
<civodul>right, so my guess is that the biggest difference is that there nodes in the DAG that are very short computations, like .c -> .o
<civodul>it’s something we could do, but not a good fit
<civodul>actually, #:imported-modules is a pre-gexp relic
<civodul>er, ECHAN