Hello,
I'm hoping for some help with a Go WASM project I am working on.
The project is based on another project of mine, which runs very well and I
have no concerns about its performance. The WASM project however performs
poorly. The help I need is to determine whether the performance of the WA
Modules in subdirectories should just work, tags are not necessary.
I see there is a recent commit to correct the module name, that was
necessary.
As for your most recent invocation, the module path was wrong (missing a
/src/ component)
$ go get
github.com/flatgeobuf/flatgeobuf/src/go@v0.0.0-2023
> I can not find the go.mod for flatbuffers! It is not in the root of the
repository and also not inside the go subdir where the code resides
Presumably relies on this:
https://go.dev/ref/mod#non-module-compat
See also
https://stackoverflow.com/questions/67030123/can-a-go-module-have-no-go-mod-f
So, I am still curious about something. Flatbuffers, which is a project I
depend on, does have its go code in a subdirectory and I can go get it:
➜ ~ 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/flatb
One good replacement is Jetbrains Rider which works on Windows and Mac. I
think on Linux as well.
gbarr schrieb am Samstag, 2. September 2023 um 19:29:55 UTC+2:
> Well that is a relief that I simply misread it.
>
> Thanks,
> Graham
>
> On Saturday, September 2, 2023 at 5:14:13 PM UTC+1 Björn Gra
Ok, this is promising. Thanks for testing it.
-Bruno
On Fri, Sep 15, 2023 at 4:58 AM Jan Mercl <0xj...@gmail.com> wrote:
> On Fri, Sep 15, 2023 at 10:31 AM 'Jim Idle' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> > The go.mod at the root was one thing that might work, but it will
Unfortunately that would be difficult for me to do as it is not my project.
I just implemented the Go version of it so I had to follow the standard
they set (implementations are inside src/[language]. But thanks for the
detailed summary of the issues. I will try the tag approach and see how it
goes
That might be doable. I will discuss this with the maintainers. Thanks for
the suggestion.
It is still a shame that workarounds like this need to exist.
-Bruno
On Fri, Sep 15, 2023 at 3:15 AM Brian Candler wrote:
> > Keep your go source at the root of the repo and tag that
>
> Or would it be
Hey Lenny.
Generally speaking @master is not required but it appears it is in this
case due to it being in a subdirectory. I understand the issues involved
(changes outside the module would affect its version anyway) but I am fine
with that as long as the module can be used. It looks to me this is
On Fri, Sep 15, 2023 at 10:31 AM 'Jim Idle' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> The go.mod at the root was one thing that might work, but it will cause
the entire repo to be pulled in so the tag will still have to be sec/go/
etc.
tl;dr: Putting a go.mod in the repository root
The go.mod at the root was one thing that might work, but it will cause the
entire repo to be pulled in so the tag will still have to be sec/go/ etc.
On Fri, Sep 15, 2023 at 15:15 Brian Candler wrote:
> > Keep your go source at the root of the repo and tag that
>
> Or would it be OK just to put
> Keep your go source at the root of the repo and tag that
Or would it be OK just to put go.mod at the root of the repo, containing
module github.com/flatgeobuf/flatgeobuf
- and leave the rest of the source where it is?
I believe that will still allow someone to import or get
github.com/flatgeobu
12 matches
Mail list logo
