Date: Sun, 23 Jan 2022 00:19:11 +0000
To: Renato Torres <renato.torres@protonmail.com>
From: Simon Ser <contact@emersion.fr>
Cc: ~emersion/hut-dev@lists.sr.ht
Reply-To: Simon Ser <contact@emersion.fr>
Subject: Re: [PATCH v1 0/1] git: show license spike
Message-ID: <VVEqWeSlVFfoMZ2hNXzVOcwM-VtrM6VF_vBqhaMIw4dtqyuGvleSLKbEU2Cxd8ync0sEEg0NfB3SzUYhdIZLRZ1eq0K9nUzT23bTaLVfi0I=@emersion.fr>
In-Reply-To: <20220122233022.1256016-1-renato.torres@protonmail.com>
References: <20220122233022.1256016-1-renato.torres@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sunday, January 23rd, 2022 at 00:31, Renato Torres <renato.torres@proton=
mail.com> wrote:
> This is not a final patch.
>
> Following one of the comments from Thorben G=C3=BCnther regarding the git
> show command, I did a spike to show the license of a repository.
>
> The command to show the license is:
>
> go run . git show hut --license
> go run . git show hut -l
>
> If used with the "license" flag the git show command shows only the
> license, shipping all the other information. This allows to fetch the
> license and use the output to feed other scripts.
>
> I was able to get the LICENSE contents by defining the query
> licenseByRepositoryName.
>
> I had an issue with this query because the Go structure returned is
> an *Object and therefore I could not cast to a TextBlob to get the
> contents of the file.
>
> To make it work I changed manually the gql.go (I know I cannot do it)
> to have the Object field be a map[string]interface{} instead of *Object:
>
> type TreeEntry struct {
> =09Id     string                 `json:"id"`
> =09Name   string                 `json:"name"`
> =09Object map[string]interface{} `json:"object"` // change
> =09Mode   int32                  `json:"mode"`
> }
>
> Questions:
>
> 1. Is this feature usefull?

I wonder. Maybe a more generally useful feature could be a cat-file command=
.

> 2. Is there a better way to get a file?

The current way sounds good.

> 3. Should we change gqlclientgen to define a Go interface{}
> when the type in the schema.graphqls is an interface?

I've been wondering about this, and I'm not sure a Go interface is the best
way to represent a GraphQL interface. Go interfaces describe common methods=
,
here what we want to do is describe common struct fields. Moreover, unless =
the
user explicitly asks for the special GraphQL "__typename" field, gqlclient =
has
no way to know the real underlying type of an Object.

Maybe instead we can generate a method on Object which takes care of the
unwrapping.

    type Object struct {
        Name string
        =E2=80=A6

        raw json.RawMessage
    }

    func (object *Object) AsTextBlob() (*TextBlob, error) {
        var textBlob TextBlob
        err :=3D json.Decode(object.raw, &textBlob)
        return textBlob, err
    }

Ideally we'd check "__typename" too, and fail on mismatch. Maybe it would b=
e a
good idea to require the user to request "__typename" for queries containin=
g
type conditions, to make sure we don't perform any erroneous type conversio=
n.

Maybe we could just have a single method to unwrap the interface:

    type Object struct {
        Name string
        =E2=80=A6

        unwrapped interface{}
    }

    func (object *Object) UnmarshalJSON(b []byte) error {
        // Unmarshal the interface fields
        =E2=80=A6

        // Unmarshal the real underlying type
        switch typeName {
        case "TextBlob":
            var textBlob TextBlob
            err :=3D json.Decode(object.raw, &textBlob)
            return textBlob, err
        default:
            return nil, fmt.Errorf("unexpected __typename %q", typeName)
        }
    }

    func (object *Object) Unwrap() interface{} {
        switch object.unwrapped
    }

This would require us to know about all implementations of a GraphQL interf=
ace
at generation time. It would seem like this is a promise we can make for si=
mple
cases, but not sure about federated GraphQL schemas and schemas split into
multiple files. Would need to do more research.

Any other ideas?

Ultimately we can always pick a solution and change it later if needed.
gqlclient is still in the early stages and we can make breaking changes if
deemed necessary.