cmd/go: handle program or library assets

[gopherbot]

by untheoretic:

Please find a reasonable way to transport things that can't be (principally) embedded in
the source code to some place where
they could be found.

An (sad) example would be a go-gtk based program that must have
a several non-go files for the gtk runtime.

[rsc]

Comment 1:

Sure, but I don't think we'll attack this for Go 1.

Labels changed: added priority-later, removed priority-triage.

Owner changed to builder@golang.org.

Status changed to Accepted.

[gopherbot]

Comment 2 by douglaspchen:

I wrote a patch that handles assets by automatically generating Go files.
https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/UOIUyn7uFsY (my post with
the diffs is in the moderation queue right now)

[minux]

Comment 3:

a .syso-based solution:
https://groups.google.com/forum/#!msg/golang-nuts/UOIUyn7uFsY/Uescy-cI7hQJ
IMHO, if cmd/go need to do this, it should do this by generating a .syso file.

[rsc]

Comment 4:

Labels changed: added go1.1maybe.

[robpike]

Comment 5:

Labels changed: removed go1.1maybe.

[rsc]

Comment 6:

[The time for maybe has passed.]

[rsc]

Comment 7:

Labels changed: added go1.2maybe.

[rsc]

Comment 8:

Labels changed: added feature.

[robpike]

Comment 9:

Still useful, but not happening in 1.2.

Labels changed: added go1.3maybe, removed go1.2maybe.

[robpike]

Comment 10:

Labels changed: removed go1.3maybe.

[rsc]

Comment 11:

Labels changed: added go1.3maybe.

[rsc]

Comment 12:

Labels changed: removed feature.

[rsc]

Comment 13:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 14:

Labels changed: added repo-main.

[gdamore]

This would be really useful. I have a JSON file that contains a database of terminals -- this file could be compiled into the Go program, but its really extension info, and adding it bloats the text of the program by some 2MB at run time. Since only about 0.1% of users need it, its better to leave it in JSON.

Ideally, go install could be made to install these resource files (perhaps by having a special file list what they are) in a standard directory based on the location of the binary, and then a little API glue to support picking the file up by the package name & binary location?

Absent this, I'm inclined to use $HOME/. and hope for the best.

[agnivade]

Just wanted to bump on this old issue.

For general stuff, the plugin model released in 1.8 should be sufficient for this. You can expose assets as a function or a variable.

In the golang-nuts thread above, folks mostly wanted to embed static assets in their binaries, which is usually done with go generate and a tool to generate the files, like statik.

@rsc @bradfitz - Are we looking to do anything more on this ?

[bradfitz]

Plugins are not the answer here. (Plugins are hard to use and not very portable)

This bug is about adding some conventions to the $GOPATH file layout, respected by the cmd/go tool, to automatically take files off the filesystem and place their contents (and perhaps their metadata like modtime) into the output, perhaps as a compressed ELF section or some equally efficient depending on the platform.

As a strawman, you could imagine a //go:embed directive that works similarly to //go:generate that cmd/go would respect to do the efficient thing. (go:generate doesn't work because we don't want to bloat git repositories by checking in base64 or hex-escaped copies of assets for every image/etc)

[agnivade]

Makes sense. Thanks !

[ngrilly]

Rust has an include_str! macro which works like this:

fn main() {
    let my_str = include_str!("spanish.in");
    assert_eq!(my_str, "adiós\n");
    print!("{}", my_str);
}

If the file spanish.in contains "adiós\n" then the program prints "adiós".

I haven't look at the implementation, but something similar in Go would be useful for example for templates and SQL queries.

[rsc]

Closing as a duplicate of #35950 which now has an active discussion.