Re: Cannot build personal channel derivation during guix pull

["Marek Paśnikowski" <marek@marekpasnikowski.pl>]

[-- Attachment #1: Type: text/plain, Size: 3326 bytes --]

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.

:-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]