guix-patches
[Top][All Lists]
Advanced

[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.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]