Small updates to the Go port.

[bruno-ga]

As I mentioned, the Go port is an ongoing thing that I will continue working on. There is something I would like to do next but I wanted to discuss it here before sending a PR.

Apparently Go modules are a bit quirky when the module is not in the root directory of the repository. The end result is that for someone to refer to the module, they need to append @master to it. Something like:

import (
    "github.com/flatgeobug/flatgeobuf/src/go@master"
)

This has no real benefit and only adds to the cognitive load.

The change that I want to do will just move the go.mod and go.sum files to the root directory of the repository. By doing that, one does not need the @master to import things (the module name will change to "github.com/flatgeobuf/flatgeobuf" but that is ok as the directory where the code is will need to be appended to it so it will look like:

import (
    "github.com/flatgeobug/flatgeobuf/src/go"
)

Which is the same as above but without the need for the @master tag.

Any objections to this?

[bjornharrtell]

Hmm, not very fond of having to move some go stuff to root of repository.

I would perhaps rather suggest then that the go implementation should live in a separate repository. But that is perhaps undesirable for other reasons.

I find it annoying that distribution/package management of a language is mandating git repo and source organisation.

[bruno-ga]

I hear ya. I would be ok with moving it to a separate repo (it is completely independent from anything else in the current repo) but I guess this would make it kind of an oddball. Anyway, I will, of course, defer it to you. I just think that the current state is the worst possible one from a Go perspective.

Maybe we could use flatgeobuf/go? If you want, you can even set me up as a maintainer so you do not need to worry too much about it.

[bjornharrtell]

I will give it some thought. I wonder how flatbuffers itself is doing?

[bjornharrtell]

It seem to refer to "github.com/google/flatbuffers/go" and I suppose that is because source lives at https://github.com/google/flatbuffers/tree/master/go.

[bjornharrtell]

I'm not against using the same organisation. I.e move content of src folder up one level.

[bruno-ga]

I will give it some thought. I wonder how flatbuffers itself is doing?

Great idea looking at flatbuffers. It looks to me it is doing some magic as I can not even find where exactly its go.mod file is. Here is a comparison between retrieving flatbuffers and flatgeobuf:

➜  ~ go get -x github.com/google/flatbuffers/go
# get https://proxy.golang.org/github.com/@v/list
# get https://proxy.golang.org/github.com/google/flatbuffers/@v/list
# get https://proxy.golang.org/github.com/google/flatbuffers/go/@v/list
# get https://proxy.golang.org/github.com/google/@v/list
# get https://proxy.golang.org/github.com/@v/list: 404 Not Found (0.156s)
# get https://proxy.golang.org/github.com/google/@v/list: 404 Not Found (0.230s)
# get https://proxy.golang.org/github.com/google/flatbuffers/go/@v/list: 200 OK (0.236s)
# get https://proxy.golang.org/github.com/google/flatbuffers/@v/list: 200 OK (0.236s)
# get https://proxy.golang.org/github.com/google/flatbuffers/go/@latest
# get https://proxy.golang.org/github.com/google/flatbuffers/go/@latest: 404 Not Found (0.023s)
go: added github.com/google/flatbuffers v23.5.26+incompatible

➜  ~ go get -x github.com/flatgeobuf/flatgeobuf/go 
# get https://proxy.golang.org/github.com/@v/list
# get https://proxy.golang.org/github.com/flatgeobuf/@v/list
# get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@v/list
# get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/go/@v/list
# get https://proxy.golang.org/github.com/@v/list: 404 Not Found (0.124s)
# get https://proxy.golang.org/github.com/flatgeobuf/@v/list: 404 Not Found (0.126s)
# get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@v/list: 200 OK (0.130s)
# get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@latest
# get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/@latest: 200 OK (0.023s)
# get https://proxy.golang.org/github.com/flatgeobuf/flatgeobuf/go/@v/list: 404 Not Found (4.152s)
go: module github.com/flatgeobuf/flatgeobuf@upgrade found (v0.0.0-20230914202020-25c11d75fe28), but does not contain package github.com/flatgeobuf/flatgeobuf/go

This might actually be easier to sort up. I guess the difference might be between having a tagged version or not. Flatbuffers obviously has an associated tag while flatgeobuf does not. Let me ask around.

[bruno-ga]

Ok, so flatbuffers is using a legacy behavior that will go away (they do not have a go.mod file). Although we could potentially do that today and it might work, we would then eventually have to fix the real underlying issue. Maybe we should then use flatgeobuf/go after all? Let me know how you want to proceed.

[bruno-ga]

Hah. It literally just started working by itself now. I guess we do not need to take any action.