Any alternative to go-bindata that supports dynamic assets?

[Mark Bauermeister]

My use case is a game engine that uses Lua scripts.
Naturally, Lua scripts can be changed during runtime without rebuilding the entire project.

Since go-bindata doesn't actually load the file during runtime but merely precompiles it to a string representation, it doesn't work for dynamic content and one of the main benefits

of using a dynamic scripting language is lost in the process.

Is there any alternative that would allow loading the files dynamically during development and baking them into the source upon release?
Or am I better off just writing some custom logic that simply tries to load the file from the file system and, upon failing, reverts to the baked data?

[Mark Bauermeister]

Actually.

To answer my own question, this probably suffices for most/all of my use cases.

func LoadScript(script string) {

    L := lua.NewState()

    defer L.Close()

    file, err := Asset(script)

    if err = L.DoFile(script); err != nil {

        L.DoString(string(file))

    }

}

[Sam Whited]

On Sun, May 26, 2019, at 13:44, Mark Bauermeister wrote:
> Is there any alternative that would allow loading the files
> dynamically during development and baking them into the source upon
> release? Or am I better off just writing some custom logic that simply
> tries to load the file from the file system and, upon failing, reverts
> to the baked data?

In my own projects I use a fork of JDB's "statik" [1] that I called
"pkgzip" [2]. The main point of forking was to avoid import side
effects, but it can load things in "dev mode" which means that it
reloads them on every refresh from the filesystem, or in live mode where
it loads them from a virtual file system that is pre-compiled. It's not
exactly what you want right now, but it would require very little
tweaking to be useful for you.

I've quickly thrown the source up here [2] and published it as
"code.soquee.net/pkgzip" in case it's useful to you or anyone else here.
The repo will likely move once SourceHut supports separate
organizations, but the vanity import will remain the same.

—Sam

P.S. Note that this package was just thrown up and DNS may not have
propagated everywhere yet. If you're getting TLS errors from
Netlify or can't look up the domain at all, wait 24 hours or so for
DNS to finish propagating and for the new certs to be deployed.

[1]: https://github.com/rakyll/statik
[2]: https://git.sr.ht/~samwhited/pkgzip

--
Sam Whited

[howar...@gmail.com]

Just a suggestion, Mark - instead of L.DoString(string(file)) in response to a failure on L.DoFile (is there no other error that can occur there other than the file being missing?), do an explicit test for the file existing, and if it does not exist, grab the asset from bindata and *write it out* - then do your L.DoFile.

While it may not seem much of a change, it means that as soon as your program runs, whatever scripts it needs get punted out onto the file system where your end user can see and fiddle with them.

Depending on your intentions, your way may be more appropriate (e.g. you only want the dynamicism to support updates rather than end-user tinkering), but this method is more discoverable if end-user tweaking is permissible.

[Ingo Oeser]

https://tech.townsourced.com/post/embedding-static-files-in-go/ is a great article comparing multiple asset embedding solutions.

You may come to different conclusion than the author depending on your own tradeoffs, but I found the comparison table very useful for making those decisions myself.