Can go:embed replace statik?

[codefromthecrypt]

Is your feature request related to a problem? Please describe.
Right now, we are having to work around unmerged change in statik. The build is also more fragile the more generation steps are involved.

Describe the solution you'd like
Ideally, we can use go:embed. There are a number of projects who have migrated in this way. For example, sascha-andres/go-logsink#36

If possible, we could remove generation commands from make and CI as a result.

Describe alternatives you've considered
Continue to maintain a fork as statik isn't really merging change we need.

Additional context
More examples https://github.com/search?q=statik+go%3Aembed&type=issues

[yskopets]

@codefromthecrypt Would you like to contribute?

From my perspective, we already have a working solution. And go:embed provides exactly the same features but slightly different API. Personally, I would prioritize other improvements.

But I understand that you might want to try go:embed in action. Please go ahead if you want to.

[codefromthecrypt]

right I mentioned mainly because statik is mostly a stalled project at this point. I wouldn't mind trying!

[codefromthecrypt]

Here's a start:

data/extension/init/templates.go

package init
//      ^^ last path in the directory relative from the project root data/extension/init

import (
	"embed"
	"io/fs"
)

// templatesFs includes only the relative path of "templates".
//
// Assets must be in this directory because go:embed doesn't support navigation outside (ex. ../)
// See https://pkg.go.dev/embed#hdr-Directives
//go:embed templates/*
var templatesFs embed.FS

// GetTemplates returns the templates directory as a filesystem
func GetTemplates() fs.FS {
	fs, err := fs.Sub(templatesFs, "templates")
	if err != nil {
		panic(err) // unexpected or a typo
	}
	return fs
}

After wiring the two call sites, there's a glitch. It seems go:embed does not allow serving directories that include go code (or go.mod).

data/extension/init/templates.go:13:12: pattern templates/*: cannot embed directory templates/tinygo: contains no embeddable files

The rationale for this constraint might be obvious to some, but not me. I added a question comment that might be answered golang/go#41191 (comment)

While this constraint exists, I don't think go:embed is usable to serve a directory of golang examples.

This adds pressure to the tools in use now, which while may work only work due to forks. If go people decide to keep the "go:embed" constraint, it could be handy to decide how to proceed, which might be to find a maintained alternative to statik, adopt our own fork of it, or let it go until it breaks... then deal with it.

Meanwhile, this issue can track and be pointed to if anyone ends up curious why we are using an abandoned library for embedding things.

[codefromthecrypt]

Seems so far the glitch is about go.mod, not files ending in .go thanks to @opennota for the hint. I added a work-in-progress PR, though I suspect we'll need to sort out go.mod one way or another #129

[yskopets]

@codefromthecrypt Personally, I would consider it a blocker for switching from statik to go:embed (more "up-to-date" library at a cost of not-doing-what-it-is-supposed-to-do doesn't make sense to me).

But I'm just one vote. If other reviewers see value in go:embed, I won't object.