Not sure this is what you're looking for, but Go 1.16 introduced an abstract filesystem interface: https://pkg.go.dev/io/fs https://go.dev/doc/go1.16#fs
"the new testing/fstest <https://go.dev/pkg/testing/fstest/> package provides a TestFS <https://go.dev/pkg/testing/fstest/#TestFS> function that checks for and reports common mistakes. It also provides a simple in-memory file system implementation, MapFS <https://go.dev/pkg/testing/fstest/#MapFS>, which can be useful for testing code that accepts fs.FS implementations." On Friday, 4 November 2022 at 21:08:09 UTC cho...@google.com wrote: > Hey all, > > I couldn't find a prior thread or other information on the web after a bit > of searching, but if this is answered elsewhere I'd appreciate a link to > follow. > > I am on a project which primarily ships a Go command line interface (CLI), > but we have aspirations of using the wasm compilation mode to also > distribute a simple webapp version of it, while sharing most of the code. > > Currently simple things work perfectly. (To everyone involved with this: > great work!) The next big hurdle is the fact that we cache things on disk > for later reuse, so things are failing out-of-the-box any time we attempt > to touch the filesystem. Luckily, in our case, the fact that we are > touching the filesystem is a bit incidental (its used as a cache for making > consecutive CLI invocations faster), and as long as the system was > consistent for the lifetime of the main Go process things will work just > fine. > > We /could/ pass a filesystem object across the codebase, and maybe we will > one day we will anyway for some other reasons, but I'd rather not have to > do that just to get further with this webapp prototype: it's a lot of > tedious plumbing, and there is a nontrivial amount of code to touch. > > So instead I decided to try some global-mutable-at-startup variables for > things like os.OpenFile, os.Remove, etc, that should be easy to cleanup if > we decide not to move forward with the prototype; but even then, there are > plenty of random things I have to do to get this to work. I've spent about > 2 hours on this direction so far and I keep hitting unexpected roadblocks - > thus this email seeking out a new strategy. > > Are there any plans to automatically support filesystems on wasm-compiled > Go applications? Even an ephemeral, in-memory filesystem would basically > solve all of my problems without having to change any code on my end, which > would be nice. > > In lieu of that, does anyone have any tips about how I could go about > doing this in a better way? > > -Kevin > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cb8dd112-0ad6-4f1a-a014-1ae3f121f20an%40googlegroups.com.
