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

[Xinglu Chen]

On Thu, Apr 01 2021, Leo Prikler wrote:

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

Oh yeah, I saw the thread on guix-devel, I should have thought of this.

>> - 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 will try and report back.

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

Good to know, I will have to mark 'go-github-com-cli-shurcool-graphql'
as hidden as well since it's GitHubs' fork of
'go-github-com-shurcool-graphql' and most likely only used by 'gh'.

>> - 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?

I am not familiar with the Go ecosystem so I don't know if this will be
possible, but I will look into it.

Thank you for the rewiew!