I’m finally continuing with my tt rewrite in Go. So, I thought I use the shiny io/fs.FS. That’s supposed to be a super cool new file system API. It allowed me to write tests more elegantly. I don’t have to place actual test files on disk, but can keep everything nicely in RAM with testing/fstest.MapFS. That actually worked out great, I do like that.

However, os.DirFS("/") for production code is just a terrible solution. I noted that OS paths and io/fs.FS paths are fundamentally different. This new API does not allow leading slashes in the passed paths. This results in an error. So, I have to cut the leading slash off myself.

Also, the whole thing is totally useless on Windows, because of the drives. Simply does not work at all. Well, honestly, I don’t care the slightest bit about that operating system, but it would be nice if this concept were cross-platform.

I haven’t tested it, but I’m pretty sure relative paths or ~ do also not work. I have to first build absolute paths myself. Unfortunately, there is no builtin helper to translate an OS path into a io/fs.FS path.

Of course, others noted these shortcomings and surprising results, too: https://github.com/golang/go/issues/44279 There is no OSFileSystem implementation that would simply allow the easy transition from all the classical os.* functionality to io/fs.FS. And they also do not wanna add something like that either. Sigh.

I’m really wondering what they were thinking when introducing this. :-?

Even though, it’s very silly, I’m gonna keep using it. At least for now. Tests have been written. I’m not keen on rewriting them. Sigh.

⤋ Read More

Participate

Login to join in on this yarn.