4 ms·

I think it's a well thought out design, particularly the implementation of some common Go interfaces (such as fs.FS) that will allow this to be transparently us

by lsllc 6y ago

I think it's a well thought out design, particularly the implementation of some common Go interfaces (such as fs.FS) that will allow this to be transparently used with existing Go code. The only thing I'd want is to allow environment variables in the "go:embed" statements, while my assets might be in the same repo and thus relative, they may also be in a different asset repo (if I'm using git I could use git submodule, but if I'm using something else that might not be possible).

yiyus 6y ago
The best way to do this with the current proposal is to write a simple go package in your assets repository and import it. Something like: package assets // import "github.com/me/myproject/assets" //go:embed * var FS embed.Files package mypackage import "github.com/me/myproject/assets" //use assets.FS Would that cover your use case?
- lsllc 6y ago
  Yeah! (as long as the UI/UX folks don't mind a bit of Go code in their repo) I was kind of hoping for: package foo //go:embed $ASSETS/* var assets embed.Files But one issue with this is that it might make a dogs breakfast of the filenames within the `assets` object -- it sort of needs something like this: //go:embed * from $ASSETS (and it would not include the $ASSETS path in the object).
  - yiyus 6y ago
    An interesting option that I've not seen proposed yet would be to accept go:embed comments before importing a package (obviating the need to write the assets package in my previous example). So, assuming your assets are in the repository github.com/me/myproject/assets, you could just do: package foo //go:embed */* import "github.com/me/myproject/assets" And the go tool would take charge of generating an assets package with assets.Files. Then we don't even need a magic embed package at all. And generating a package would give us more flexibility, for example: package foo // import "foo.io/foo" //go:embed Name string "name.txt" //go:embed Data []byte "bin.dat" //go:embed "images" "templates" "html/index.html" import embedded "foo.io/foo" //use embedded.Name, with type string //use embedded.Data, with type []byte //use embedded.Files, with type fs.FS

by lsllc 6y ago

yiyus 6y ago

The best way to do this with the current proposal is to write a simple go package in your assets repository and import it. Something like: package assets // import "github.com/me/myproject/assets" //go:embed * var FS embed.Files package mypackage import "github.com/me/myproject/assets" //use assets.FS Would that cover your use case?

lsllc 6y ago
Yeah! (as long as the UI/UX folks don't mind a bit of Go code in their repo) I was kind of hoping for: package foo //go:embed $ASSETS/* var assets embed.Files But one issue with this is that it might make a dogs breakfast of the filenames within the `assets` object -- it sort of needs something like this: //go:embed * from $ASSETS (and it would not include the $ASSETS path in the object).
- yiyus 6y ago
  An interesting option that I've not seen proposed yet would be to accept go:embed comments before importing a package (obviating the need to write the assets package in my previous example). So, assuming your assets are in the repository github.com/me/myproject/assets, you could just do: package foo //go:embed */* import "github.com/me/myproject/assets" And the go tool would take charge of generating an assets package with assets.Files. Then we don't even need a magic embed package at all. And generating a package would give us more flexibility, for example: package foo // import "foo.io/foo" //go:embed Name string "name.txt" //go:embed Data []byte "bin.dat" //go:embed "images" "templates" "html/index.html" import embedded "foo.io/foo" //use embedded.Name, with type string //use embedded.Data, with type []byte //use embedded.Files, with type fs.FS