[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#39021] [PATCH] Add Keybase
From: |
Jakub Kądziołka |
Subject: |
[bug#39021] [PATCH] Add Keybase |
Date: |
Tue, 11 Feb 2020 17:36:54 +0100 |
> > From 3de233a2d8e6bdb4723844337b69b6612616c9c5 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Jakub=20K=C4=85dzio=C5=82ka?= <address@hidden>
> > 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.
signature.asc
Description: PGP signature