IRC channel logs
2023-10-16.log
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>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>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