[bug#47539] [PATCH 00/28] Add gh and dependencies

[Leo Prikler]

Hi,

Am Donnerstag, den 01.04.2021, 09:51 +0200 schrieb Xinglu Chen:
> This patchset adds the 'gh' package, a CLI interface to GitHub.  The
> Go
> importer did most of the work. :)
I am not experienced with Go, so I can't comment on the rest too much,
but I wanted to point out, that single, double and triple letter
packages are (imo rightly) frowned upon in the Guix project. 
Considering, that this is the *official* Github CLI tool, a name like
"github-cli" would probably make more sense here.

> Some things to note:
> 
> - When building'gh', I couldn't get
>   'go-github-com-charmbracelet-glamour' to build without moving some
>   native-inputs to propagated-inputs, though, if I was only building
>   'go-github-com-charmbracelet-glamour' it would build without moving
>   things to propagated-inputs.  I am not sure why this happens.
Perhaps you need to add those native inputs as native inputs to gh as
well?  Try adding its native inputs to gh and see whether that changes
something.

> - I found that (gnu packages syncthing) contained quite a few Go
>   packages, I think it would make sense to move those packages to
> (gnu
>   packages golang), and move the Syncthing package to (gnu packages
>   sync).  This would be done in a separate commit though.
Indeed, that should probably done in a separate set.

> - The patch marked with 'D' adds a package which has been deprecated
> by
>   upstream, but it is still needed by one of the packages that 'gh'
>   depend on.  I have marked it as a hidden package, let me know if
> this
>   is the right decision.
Yes, we do so for other packages as well, that require outdated or
otherwise modified versions, that should not show up in user profiles
unless they really, really want to and use manifests to achieve their
goals.

> - The patch marked with 'W' adds a package which is needed by 'gh',
> but
>   only used on Windows.  It is still Free Software (BSD-2), but I
> have
>   also marked it as hidden.
This is at least in some sense an acceptable workaround, but how large
would the effort be to outright drop references to this package, given
that it's already not "actively" being used?

Regards,
Leo