Gno file compatibility with Go tooling

[thehowl]

gnolang/gno#472 introduced linter support on the repository. These are however still not enabled for .gno files. Forking the linter to allow it to run also on gno files is probably impractical; and there also remains the issue of all other Go tooling which would be useful but doesn't currently work. For the scope of this issue, I think the tools which would be very much needed in Gno for a pleasant development experience are linters (golangci-lint, revive, staticcheck ...) and gopls (for text editor autocompletion, etc.)

While some tooling does have purpose in being rewritten to adapt to gno, the Go ecosystem is pretty vast, so it'd probably be better if there was a way to have a "compatibility layer" where the rest of the tooling can operate.

My idea: create a command in gnodev which creates a FUSE filesystem with go-fuse. In this filesystem we have both a GOROOT (containing the source code for the standard library, etc) and a GOPATH. The files inside are the gno files precompiled.

The filesystem would be "mostly" readonly, as formatters are better off executing directly on gno code (maybe supporting goimports-style functionality could be a bit trickier, though if anything this would be something to be done with gopls as in most editors that is what is currently providing the automatic imports), but the way I see it using a filesystem which can "emulate" a normal Go environment (by means of also in the future supporting remote packages and realms) is probably one of the easiest ways to make a lot of tooling work without having to maintain large amounts of code.

Very much open to different ideas as I can very easily see doing a FUSE mount having lots of impracticalities (full support only on linux, implementation of gopls in text editors would probably still mean changing extensions in text editors so that they can work on the gno files while having the tools like gopls and linters work on the FUSE-mounted files instead). The easier and less set up it requires to bridge existing tools to Gno, as well as for end users setting up their coding environment to have go tools in gno, the better.

---

See also: gnolang/gno#453

[moul]

I'm interested in working on this idea as a side project for fun. However, depending on Fuse for such needs seems too restrictive. Let's consider other ideas first and keep this concept on the side, like #36.

[moul]

What about moving those topics to the https://github.com/gnolang/hackerspace repo?

[thehowl]

Yes, I recall we discussed this idea via voice but didn't share further thoughts here. I think another interesting idea instead of FUSE would be that of making an implementation of io/fs.FS, which then can be plugged into other go tools' filesystem access calls, in pretty much the same way FUSE works.

I'm fine with moving this to hackerspace :)

[moul]

Perhaps we can leverage the LD_PRELOAD approach, where gno fmt essentially triggers LD_PRELOAD=gno2gofs.so go fmt.

[moul]

FYI, I've previously tinkered on Go embedding/calling binaries:

• Mister-bin
• Dockerself

[moul]

Related with gnolang/gno#972