> > From 3de233a2d8e6bdb4723844337b69b6612616c9c5 Mon Sep 17 00:00:00 2001 > > From: =?UTF-8?q?Jakub=20K=C4=85dzio=C5=82ka?= > > Date: Tue, 7 Jan 2020 20:29:21 +0100 > > Subject: [PATCH 2/2] gnu: Add keybase. > > > > * gnu/packages/crypto.scm > > (keybase-component): New function. > > (keybase, git-remote-keybase, kbfs): New variables. > > This is enough of it's own thing that we can make a new (gnu packages > keybase) module. Sure, will do. > > +(define* (keybase-component #:key name repo-path synopsis description) > > We avoid abbreviations, so maybe "repository-path"? Bonus points if we > can make it more descriptive. I can't think of anything more descriptive, as it's literally the path in the repository the component is at. > Can you take a look at the bundled ("vendored") dependencies: > > https://github.com/keybase/client/tree/master/go/vendor > > We strive to avoid using these, but sometimes we do, as in the Docker > package. It's not really idiomatic to unbundle things in Go. But we need > to at least make sure all the bundled dependencies are freely licensed. Apart from licensing concerns, what are the arguments for splitting this into separate packages? I feel like this is just busywork... > Also, please run `guix lint` on these packages and make sure the > descriptions are written in complete sentences. Ah, sure, somehow I forgot to do this before.