Packr Box as migration source.

[chakrit]

Is your feature request related to a problem? Please describe.
go-bindata has been left unmaintained, unwillingly or otherwise. See
jteeuwen/go-bindata#5

This presents a problem as we're using go-bindata to embed our migration files into our Go binaries. The next best alternative is https://github.com/gobuffalo/packr

Describe the solution you'd like
Migration source support for packr boxes.

Describe alternatives you've considered
N/A

Additional context
N/A

[chakrit]

Threw this together quickly: https://gist.github.com/chakrit/f0f685dc224013ea3b2c3e2e8ac77a34 in case anyone wants to make a proper PR out of it.

[dhui]

Feel free to open a PR. Don't forget to add tests.

[adelowo]

I can send a PR ( plus tests ) for this before Saturday

[maxekman]

Would be awesome to get Packr support merged.

[adelowo]

Damn, I forgot about this.... Will send in the PR on Sunday evening

[coolaj86]

Hey hey! I was just about to work on something similar.

What are your thoughts on using the http.FileServer webdav.FileSystem http.FileSystem interface so that it'll work with gobindata, fileb0x, vfsgen, and all of the other bindata packers as well?

[dhui]

@coolaj86 What do we gain by using another interface?

I see the following issues with using another interface/struct (http.FileServer or webdav.FS):

1. The interface needs to provide a way to "list" files which is necessary to read the next/previous migration to run. See the migrate.source.Driver interface.
   • It doesn't look like http.FileServer or webdav.FS provide a method for listing files.
2. Using another interface won't save any work since you'll need to integrate the bin packer with the other interface, which should be roughly the same amount of work as integrating with migrate.source.Driver
3. Specifying the source driver would stumble. e.g. the schema would look something like http+go-bindata:// or webdav+go-bindata:// instead of go-bindata://

[adelowo]

Hey @coolaj86, let me know if you are picking this one up

[coolaj86]

@dhui @adelowo This is what I meant: #144

Obviously you'll want more docs and whatnot, but that shows how it could work.

http.FileSystem is the "canonical" FileSystem implementation that almost everyone who is making any sort of FS abstraction conforms to. It only differs from os.Open and os.File.Readdir in that it's an interface rather than a struct. Or at least I think I said that right.

[coolaj86]

The interface needs to provide a way to "list" files which is necessary to read the next/previous migration to run. See the migrate.source.Driver interface. It doesn't look like http.FileServer or webdav.FS provide a method for listing files.

They both use http.File which must implement http.File.Readdir (same as os.Readdir).

ioutil.ReadDir is just a convenience wrapper over os.Readdir. Whereas the os package defines a singleton with several wrappers, http.File defines an interface. An os.File implements http.File.

Intuitively, you'd think that http.File would implement an interface from os, not the other way around... but that's just how the cookie crumbled as the language evolved.

Using another interface won't save any work since you'll need to integrate the bin packer with the other interface, which should be roughly the same amount of work as integrating with migrate.source.Driver

The point is that packr, fileb0x, vfsgen, and most other bindata generators already implement http.FileSystem and/or webdav.FileSystem, so there's no need to do any work.

The plugins for packr and fileb0x that I included in my PR are essentially no-op wrappers. The only reason to have such a plugin is for SEO benefit and for the benefit of people who didn't read or understand the documentation of those packages as implementing the http.FileSystem and webdav.FileSystem interfaces (which I didn't understand at first either).

Specifying the source driver would stumble. e.g. the schema would look something like http+go-bindata:// or webdav+go-bindata:// instead of go-bindata://

It's all the same interface (see the code in the PR). A single fs:// namespace would handle all cases. The only reason to have separate names would be for the benefit of documentation and SEO.

[dhui]

A single fs:// namespace would handle all cases. The only reason to have separate names would be for the benefit of documentation and SEO.

I believe we'll still need to register the each source driver for the following reasons:

1. Need to import the wrapped source driver. e.g. packr, fileb0x, etc
2. User visibility. e.g. users know what source drivers are available via the docs and CLI

[dhui]

This should be trivial to implement now that #293 has been merged.
Also, it looks like there's yet another packer/packager...
https://github.com/markbates/pkger

[dhui]

Closing since pkgr is supported. If anyone wants packr support, they can still open a PR and add it.