Introduction

Well, it’s been a while xD Since my last entry a lot has changed, so let’s cut to the chase!

Docker

The majority of my contributions to Guix has been packaging Docker’s dependencies. We keep the progress in this Milestone created by Hellseher. I submit my contributions in batches of about 20 packages each and, until now, I’ve submitted 7 batches, totalizing 92 commits, the most recent one being the PR #7580.

As I commented in my first journal entry, Guix is a source based distribution. So its package repository is actually a set of package recipes (also called package definitions) that describes how to compile a given software. In this way, to “package” a software, I need to write its package recipe and submit it to the Guix git repository. Each recipe is submitted as a commit.

Fortunaly, there is a tool, namely guix import, to help write this package definitions. So the first thing I did was to run guix import go --recursive github.com/moby/moby. The command guix import go fetches data from a given package (in this case, github.com/moby/moby) and produces its recipe and the flag --recursive calls guix import for each unpackaged dependency of the target project recursively. In this way, after a very long time fetching all the necessary data, guix import generated a very huge file containing all the recipes!

The next step is to find a recipe in this file which has all dependencies already packaged, test if it actually compiles (remember that some tests from the upstream package may fail) and submit it to guix.

This process is very tiresome and unmotivating:

  • It is tiresome just because the amount of packages in the generated file is overwhelming and the dependency graph makes it a mess to choose a package to work with.

  • It is specially unmotivating, because this generated file doesn’t explain to you the context of each package. To better ilustrate this point, let me draw an example: In the third batch, I package go-github-com-tonistiigi-go-csvvalue, a Go library to read csv values. Why in the hell would Docker use it? Even if indirectly? How does this package fit in the dependency graph? I mean, I know some packages depend on in, I can find them in the generated file, but theses others packages are also os disconnected from the ideia of Docker that it seems a waste of time to package them.

It is not enough to aimlessly work on this packages. I had to organize myself in a way to keep my focus and motivation!

I’ll write a dedicated post about it, because I really think it deserves a post by itself and because I’m already kind of tired of writing xD

Getting into the Guix’s Go team

After some batches, I wanted to contribute something other than a package definition. So I decided to pick the bug #3968 to fix!

Since I wasn’t in a team, Hellseher couldn’t assign the issue to me, so he asked me to join the Go team!

I was very happy with this and commited my named into the teams.scm file and created a PR. After that, the Hellseher merged my commit adding me to the Go team.

I’ll write a post about this bug once I fix it!

Conclusion

I’m very happy with my progress contributions in the Guix community! :D