27.01.2024 18:27:23 CET Parnikkapore via: > That "import a local directory with secrets" trick seems like a nice one to > have in the bag!
It really is. Last night I also came up with a more general notion of "private inputs". Those could be not only secrets, but also things like channel branch names in the channels.scm files. Basically any data that does not really need to be version tracked, or data which you do not want to track, like options which you want to experiment with in a wip-branch, without having to commit every time you flip an A/B test... The private inputs allow you to technically maintain functional purity, even if in the view of a particular repository, you create something that looks like side effects. > There's an extra law of Guix channels: all files within the file tree whose > name ends with .scm must be runnable in the build environment (i.e. no > network, no access to e.g. your home directory, etc.). This means that > `guix repl -L $FILE_TREE_ROOT $FILE_TREE_ROOT/any/file.scm` must run and > terminate without throwing any unhandled exceptions. (passing this test > doesn't guarantee that it will work, however.) That makes total sense to me. I was not able to deduce that, because I only used "guix home reconfigure" and "guix pull" as my test suite. This means I was always using the isolated environment, and thus was not able to see the differences to a "guix repl". > I'm not sure if having .scm files that are not modules within the file tree > would themselves cause a problem, but doing so is definitely unsupported > territory. I have already proven that it is not possible to include .scm files which are not modules. Guix will complain that there is "no code for module (whatever file path)" when pulling. > One more thing: the root of the "file tree" need not be the root of the Git > repo; it can be a subdirectory inside the repo. See > https://guix.gnu.org/manual/devel/en/html_node/Package-Modules-in-a-Sub_002 > ddirectory.html . In fact, this might be a more appropriate solution for > your monorepo - see > https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuo > us-integrationthe-ultimate-guide-to-software-development-with-guix/ for an > example. Yes, the (directory) field of (channel) in .guix-channel . This is why a guix channel must not be equal to a version tracked repository. I would like to kindly remind everyone who reads this not to assume things too much. My personal /git/channel.git WAS not, IS not, and WILL not be a monorepo. What it happens to be is that it is my first stab at creation of a remote channel. Right now it is catch-all for my existing system and home configurations. However, for every piece of software I package, I will do so in a new channel, which is a fork of the software's repository. And I do have a grand dream of writing my own distribution of Guix, which will warrant yet another channel, if not more. Also, I personally dislike the monolith architecture. This is why my codebase right now is such a tangled mess - I tried using the noweb feature of Emacs Org, but that thing does not scale well... And now I have more pressing problems to solve than a refactor, which I will have to do regardless, when I eventually learn to define parameterized services. :-)
signature.asc
Description: This is a digitally signed message part.
