New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: handle program or library assets #3035

Open
gopherbot opened this Issue Feb 15, 2012 · 19 comments

Comments

Projects
None yet
8 participants
@gopherbot

gopherbot commented Feb 15, 2012

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

This comment has been minimized.

Contributor

rsc commented Feb 15, 2012

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

This comment has been minimized.

gopherbot commented Aug 7, 2012

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

This comment has been minimized.

Member

minux commented Aug 8, 2012

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

This comment has been minimized.

Contributor

rsc commented Sep 12, 2012

Comment 4:

Labels changed: added go1.1maybe.

@robpike

This comment has been minimized.

Contributor

robpike commented Mar 7, 2013

Comment 5:

Labels changed: removed go1.1maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Mar 12, 2013

Comment 6:

[The time for maybe has passed.]
@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 7:

Labels changed: added go1.2maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 8:

Labels changed: added feature.

@robpike

This comment has been minimized.

Contributor

robpike commented Aug 16, 2013

Comment 9:

Still useful, but not happening in 1.2.

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

@robpike

This comment has been minimized.

Contributor

robpike commented Aug 20, 2013

Comment 10:

Labels changed: removed go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 11:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 12:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 13:

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

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 14:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@gdamore

This comment has been minimized.

gdamore commented Oct 9, 2015

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

This comment has been minimized.

Member

agnivade commented Nov 3, 2018

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

This comment has been minimized.

Member

bradfitz commented Nov 5, 2018

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

This comment has been minimized.

Member

agnivade commented Nov 5, 2018

Makes sense. Thanks !

@ngrilly

This comment has been minimized.

ngrilly commented Nov 5, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment