Re: [go-nuts] proposal: embed static assets

[John Unland]

On Wednesday, May 2, 2018 at 3:12:58 PM UTC-5, Manlio Perillo wrote:

> Yes, but many developers may need a "debug" mode or more options available 
> to where to store the assets.
> Why should a "standard" tool or API be restricted to where to store assets?
>

 I can kinda see where your going with having a debug mode. I've looked 
around too see what kinda tools are out there and found some in the 
awesome-go  repo.

Looking at some of these tools, packr looks like a tool that might work / 
be a good model for a standard tool:



*In order to get static files into a Go binary, those files must firstbe 
converted to Go code. To do that, Packr, ships with a few tools to help 
build binaries. See below.*

*During development, however, it is painful to have to keep running a tool 
to compile those files.*

*Packr uses the following resolution rules when looking for a file:*


   1. *Look for the file in-memory (inside a Go binary)*
   2. *Look for the file on disk (during development)*

From: https://github.com/gobuffalo/packr

Would something like this be a good model?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

Il giorno mercoledì 2 maggio 2018 21:53:50 UTC+2, Jan Mercl ha scritto:
>
> On Wed, May 2, 2018 at 9:23 PM Manlio Perillo  > wrote:
>
> > Note that you can load assets of any package, not only of the "current" 
> package.
>
> No doubt that's useful, but the topic of this thread is about embedded, 
> static assets, fixed at link time.
>

Yes, but many developers may need a "debug" mode or more options available 
to where to store the assets.
Why should a "standard" tool or API be restricted to where to store assets?

I prefer to store assets in the package source directory since it is more 
flexible (e.g. can be loaded by the fronted Nginx server), and a standard 
tool that only handle embed static assets will be probably useless to me.


> [...]

Manlio 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Jan Mercl]

On Wed, May 2, 2018 at 9:23 PM Manlio Perillo 
wrote:

> Note that you can load assets of any package, not only of the "current"
package.

No doubt that's useful, but the topic of this thread is about embedded,
static assets, fixed at link time.
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

Il giorno mercoledì 2 maggio 2018 20:47:19 UTC+2, Jan Mercl ha scritto:
>
> On Wed, May 2, 2018 at 8:31 PM Manlio Perillo  > wrote:
>
> > The interface is different.
> >
> > Open(pkg, path string) ...
>
> Please explain why the 'pkg' argument is needed. Paths can encode any 
> hierarchy.
>
>
This is a function that I wrote some time ago to load an asset stored in 
the package source code directory:
https://play.golang.org/p/u9ba9DUInEJ

Note that you can load assets of any package, not only of the "current" 
package.
This is different from tools like https://github.com/rakyll/statik.


> [...]


Manlio 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Jan Mercl]

On Wed, May 2, 2018 at 8:31 PM Manlio Perillo 
wrote:

> The interface is different.
>
> Open(pkg, path string) ...

Please explain why the 'pkg' argument is needed. Paths can encode any
hierarchy.

> You also need the package import path to load an asset.

I do not understand the connection.

FTR: In my projects I'm using https://github.com/cznic/httpfs on top of
https://github.com/cznic/assets.



-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

Il giorno mercoledì 2 maggio 2018 20:02:12 UTC+2, Jan Mercl ha scritto:
>
> On Wed, May 2, 2018 at 7:39 PM Manlio Perillo  > wrote:
>
> > type Asset interface
>
> bike shedding: type Assets = http.FileSystem 
> -- 
>

The interface is different.
 
Open(pkg, path string) ...

You also need the package import path to load an asset.


Manlio 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Jan Mercl]

On Wed, May 2, 2018 at 7:39 PM Manlio Perillo 
wrote:

> type Asset interface

bike shedding: type Assets = http.FileSystem
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

Il giorno mercoledì 2 maggio 2018 19:23:59 UTC+2, Manlio Perillo ha scritto:
>
> Il giorno mercoledì 2 maggio 2018 17:51:24 UTC+2, Robert Johnstone ha 
> scritto:
>>
>> Before there was a wide range of tools for embedding assets, I wrote my 
>> own.  It is relatively complete, but it did not have a feature to create a 
>> debug mode for assets.  However, the server took a command-line flag for 
>> debug mode, and would access assets through the file system instead of the 
>> embedded data.
>>
>> The point being, the "standard" tool would not have to support 
>> everything, it could be a building block for other packages.  The key 
>> functionality would be embedding possibly large assets into the linked 
>> executable.  I haven't measured in a while, but embedding assets did have a 
>> significant impact on build times.  Finding the most efficient technique 
>> would be a usable block, all on its own.  Additional conveniences could be 
>> built on top.
>>
>> Robert
>>
>>
>
> Beside a "standard" tool, maybe we need a "standard" interface; e.g.
> package data
>
>
> type Asset interface {
> Load(path string) (io.Reader, error)
> }
>
>
Sorry, there is an error.
It should be

type Asset interface {
// Open opens the asset of the specified package at the specified 
path.
//
// pkg must be the full import path of the package.  path must be a 
relative
// path.
Open(pkg, path string) (io.Reader, error)
}

 

> and have some default implementations.
>
> Assets can be stored in several place, like
>   - Global system path (/usr/share)
>   - Local system path (/usr/local/share)
>   - User path (~/.local/share)
>   - A Custom path
>   - Embedded in the executable
>
>
And, of course, can be also be stored in the package source code directory.


Manlio 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

Il giorno mercoledì 2 maggio 2018 17:51:24 UTC+2, Robert Johnstone ha 
scritto:
>
> Before there was a wide range of tools for embedding assets, I wrote my 
> own.  It is relatively complete, but it did not have a feature to create a 
> debug mode for assets.  However, the server took a command-line flag for 
> debug mode, and would access assets through the file system instead of the 
> embedded data.
>
> The point being, the "standard" tool would not have to support everything, 
> it could be a building block for other packages.  The key functionality 
> would be embedding possibly large assets into the linked executable.  I 
> haven't measured in a while, but embedding assets did have a significant 
> impact on build times.  Finding the most efficient technique would be a 
> usable block, all on its own.  Additional conveniences could be built on 
> top.
>
> Robert
>
>

Beside a "standard" tool, maybe we need a "standard" interface; e.g.
package data


type Asset interface {
Load(path string) (io.Reader, error)
}

and have some default implementations.

Assets can be stored in several place, like
  - Global system path (/usr/share)
  - Local system path (/usr/local/share)
  - User path (~/.local/share)
  - A Custom path
  - Embedded in the executable

 
Manlio


> On Wednesday, 2 May 2018 10:36:43 UTC-4, mbanzon wrote:
>>
>> I’m guessing that everyone who has a workflow where they currently embed 
>> resources in their binary will have specific wishes to how it’ll function.
>>
>> The “easy” way to make serious proposals is to provide an experiment 
>> where you demonstrate the change you are proposing with an implementation - 
>> this will naturally require some work.
>>
>> My/our use of embedded resources include other programs but especially 
>> frontends (html, css, javascript and images, fonts etc.) for web servers - 
>> the current solution give us a crucial feature: The files are not embedded 
>> during development/debugging where they change continually.
>>
>> There is no doubt that I’d welcome this feature in the standard Go 
>> toolchain - where it is implemented or how the resource is embedded is not 
>> really something I have a strong opinion about - but debugging capabilities 
>> is ;-)
>>
>> -- 
>> Michael Banzon
>> https://michaelbanzon.com/
>>
>>
>>
>>
>> Den 2. maj 2018 kl. 14.35 skrev Manlio Perillo :
>>
>> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha 
>> scritto:
>>>
>>> On Tue, May 1, 2018 at 1:28 PM, John Unland  wrote: 
>>> > 
>>> > So something like x/tools/cmd/assets or cmd/assets? 
>>>
>>> Yes.  I might use a name more like cmd/embed. 
>>>
>>>
>>> > I was just now thinking about it more today and I was wondering if 
>>> something 
>>> > like this could maybe be implemented into go build. Like how you can 
>>> assign 
>>> > variables at build time: 
>>> > 
>>> > go build -ldflags="-X main.Foo=Bar" 
>>> > 
>>> > Into something like... 
>>> > 
>>> > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB" 
>>> > 
>>> > Think this would take a little more effort to integrate in but it's a 
>>> > interesting concept thou. 
>>>
>>> Personally I think the code generation approach is simpler. 
>>>
>>>
>> It is simpler but, isn't it very inefficient with large assets, since the 
>> compiler eats a lot of memory?
>> Maybe a better choice is to directly embed the code into the executable 
>> image, as an example appending a zip archive at the end of the executable 
>> (this at least works with ELF on Linux).
>>
>> Using a zip archive appended to the end of the executable, you don't even 
>> need to record the offset.
>> The unzip tool just reports a warning:
>> warning [xxx]:  ddd extra bytes at beginning or within zipfile
>>
>> I have not tested it with the archive/zip package.
>>
>>
>> Manlio 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

On Wed, May 2, 2018 at 6:45 PM, Ian Lance Taylor  wrote:
> On Wed, May 2, 2018 at 5:35 AM, Manlio Perillo  
> wrote:
>> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha
>> scritto:
>>
>>> Personally I think the code generation approach is simpler.
>>>
>>
>> It is simpler but, isn't it very inefficient with large assets, since the
>> compiler eats a lot of memory?
>
> That sounds like a fixable problem.  If there is an expected way to
> embed data, we can make sure that the compiler handles that expected
> way efficiently.
>

This seems the best solution.
Maybe it may help to introduce a custom directive like
  //go:asset
that can hint the compiler to parse and store the data in an efficient way.

The only possible problem is that storing large assets as code may
increase the executable loading time by the operating system (and
consume more virtual memory but I'm not sure).


Manlio

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Ian Lance Taylor]

On Wed, May 2, 2018 at 5:35 AM, Manlio Perillo  wrote:
> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha
> scritto:
>
>> Personally I think the code generation approach is simpler.
>>
>
> It is simpler but, isn't it very inefficient with large assets, since the
> compiler eats a lot of memory?

That sounds like a fixable problem.  If there is an expected way to
embed data, we can make sure that the compiler handles that expected
way efficiently.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Robert Johnstone]

Before there was a wide range of tools for embedding assets, I wrote my 
own.  It is relatively complete, but it did not have a feature to create a 
debug mode for assets.  However, the server took a command-line flag for 
debug mode, and would access assets through the file system instead of the 
embedded data.

The point being, the "standard" tool would not have to support everything, 
it could be a building block for other packages.  The key functionality 
would be embedding possibly large assets into the linked executable.  I 
haven't measured in a while, but embedding assets did have a significant 
impact on build times.  Finding the most efficient technique would be a 
usable block, all on its own.  Additional conveniences could be built on 
top.

Robert


On Wednesday, 2 May 2018 10:36:43 UTC-4, mbanzon wrote:
>
> I’m guessing that everyone who has a workflow where they currently embed 
> resources in their binary will have specific wishes to how it’ll function.
>
> The “easy” way to make serious proposals is to provide an experiment where 
> you demonstrate the change you are proposing with an implementation - this 
> will naturally require some work.
>
> My/our use of embedded resources include other programs but especially 
> frontends (html, css, javascript and images, fonts etc.) for web servers - 
> the current solution give us a crucial feature: The files are not embedded 
> during development/debugging where they change continually.
>
> There is no doubt that I’d welcome this feature in the standard Go 
> toolchain - where it is implemented or how the resource is embedded is not 
> really something I have a strong opinion about - but debugging capabilities 
> is ;-)
>
> -- 
> Michael Banzon
> https://michaelbanzon.com/
>
>
>
>
> Den 2. maj 2018 kl. 14.35 skrev Manlio Perillo  >:
>
> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha 
> scritto:
>>
>> On Tue, May 1, 2018 at 1:28 PM, John Unland  wrote: 
>> > 
>> > So something like x/tools/cmd/assets or cmd/assets? 
>>
>> Yes.  I might use a name more like cmd/embed. 
>>
>>
>> > I was just now thinking about it more today and I was wondering if 
>> something 
>> > like this could maybe be implemented into go build. Like how you can 
>> assign 
>> > variables at build time: 
>> > 
>> > go build -ldflags="-X main.Foo=Bar" 
>> > 
>> > Into something like... 
>> > 
>> > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB" 
>> > 
>> > Think this would take a little more effort to integrate in but it's a 
>> > interesting concept thou. 
>>
>> Personally I think the code generation approach is simpler. 
>>
>>
> It is simpler but, isn't it very inefficient with large assets, since the 
> compiler eats a lot of memory?
> Maybe a better choice is to directly embed the code into the executable 
> image, as an example appending a zip archive at the end of the executable 
> (this at least works with ELF on Linux).
>
> Using a zip archive appended to the end of the executable, you don't even 
> need to record the offset.
> The unzip tool just reports a warning:
> warning [xxx]:  ddd extra bytes at beginning or within zipfile
>
> I have not tested it with the archive/zip package.
>
>
> Manlio 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Michael Banzon]

I’m guessing that everyone who has a workflow where they currently embed 
resources in their binary will have specific wishes to how it’ll function.

The “easy” way to make serious proposals is to provide an experiment where you 
demonstrate the change you are proposing with an implementation - this will 
naturally require some work.

My/our use of embedded resources include other programs but especially 
frontends (html, css, javascript and images, fonts etc.) for web servers - the 
current solution give us a crucial feature: The files are not embedded during 
development/debugging where they change continually.

There is no doubt that I’d welcome this feature in the standard Go toolchain - 
where it is implemented or how the resource is embedded is not really something 
I have a strong opinion about - but debugging capabilities is ;-)

-- 
Michael Banzon
https://michaelbanzon.com/




> Den 2. maj 2018 kl. 14.35 skrev Manlio Perillo :
> 
> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha scritto:
> On Tue, May 1, 2018 at 1:28 PM, John Unland > wrote: 
> > 
> > So something like x/tools/cmd/assets or cmd/assets? 
> 
> Yes.  I might use a name more like cmd/embed. 
> 
> 
> > I was just now thinking about it more today and I was wondering if 
> > something 
> > like this could maybe be implemented into go build. Like how you can assign 
> > variables at build time: 
> > 
> > go build -ldflags="-X main.Foo=Bar" 
> > 
> > Into something like... 
> > 
> > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB" 
> > 
> > Think this would take a little more effort to integrate in but it's a 
> > interesting concept thou. 
> 
> Personally I think the code generation approach is simpler. 
> 
> 
> It is simpler but, isn't it very inefficient with large assets, since the 
> compiler eats a lot of memory?
> Maybe a better choice is to directly embed the code into the executable 
> image, as an example appending a zip archive at the end of the executable 
> (this at least works with ELF on Linux).
> 
> Using a zip archive appended to the end of the executable, you don't even 
> need to record the offset.
> The unzip tool just reports a warning:
> warning [xxx]:  ddd extra bytes at beginning or within zipfile
> 
> I have not tested it with the archive/zip package.
> 
> 
> Manlio 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Manlio Perillo]

Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha 
scritto:
>
> On Tue, May 1, 2018 at 1:28 PM, John Unland  > wrote: 
> > 
> > So something like x/tools/cmd/assets or cmd/assets? 
>
> Yes.  I might use a name more like cmd/embed. 
>
>
> > I was just now thinking about it more today and I was wondering if 
> something 
> > like this could maybe be implemented into go build. Like how you can 
> assign 
> > variables at build time: 
> > 
> > go build -ldflags="-X main.Foo=Bar" 
> > 
> > Into something like... 
> > 
> > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB" 
> > 
> > Think this would take a little more effort to integrate in but it's a 
> > interesting concept thou. 
>
> Personally I think the code generation approach is simpler. 
>
>
It is simpler but, isn't it very inefficient with large assets, since the 
compiler eats a lot of memory?
Maybe a better choice is to directly embed the code into the executable 
image, as an example appending a zip archive at the end of the executable 
(this at least works with ELF on Linux).

Using a zip archive appended to the end of the executable, you don't even 
need to record the offset.
The unzip tool just reports a warning:
warning [xxx]:  ddd extra bytes at beginning or within zipfile

I have not tested it with the archive/zip package.


Manlio 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Ian Lance Taylor]

On Tue, May 1, 2018 at 1:28 PM, John Unland  wrote:
>
> So something like x/tools/cmd/assets or cmd/assets?

Yes.  I might use a name more like cmd/embed.


> I was just now thinking about it more today and I was wondering if something
> like this could maybe be implemented into go build. Like how you can assign
> variables at build time:
>
> go build -ldflags="-X main.Foo=Bar"
>
> Into something like...
>
> go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB"
>
> Think this would take a little more effort to integrate in but it's a
> interesting concept thou.

Personally I think the code generation approach is simpler.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[John Unland]

So something like *x/tools/cmd/assets* or *cmd/assets*?

I was just now thinking about it more today and I was wondering if 
something like this could maybe be implemented into *go build*. Like how 
you can assign variables at build time:

*go build -ldflags="-X main.Foo=Bar"*

Into something like...



*go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB"*Think 
this would take a little more effort to integrate in but it's a interesting 
concept thou.

On Monday, April 30, 2018 at 2:57:12 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Apr 30, 2018 at 12:10 PM, John Unland  > wrote: 
> > 
> > Don't think so, I think most tools out there have the same basic premise 
> > behind embedding assets. I think it would be great to have one standard 
> tool 
> > into the stdlib. Since Go is a language for the web this would align 
> greatly 
> > with something like this. 
>
> I think the place for such a standardized tool would 
> golang.org/x/tools, along the lines of cmd/stringer which is there 
> today. 
>
> Ian 
>
>
> > On Monday, April 30, 2018 at 1:09:02 PM UTC-5, Ian Lance Taylor wrote: 
> >> 
> >> On Mon, Apr 30, 2018 at 7:03 AM, John Unland  
> wrote: 
> >> > 
> >> > Hey everyone I've been mulling over this for a couple of days, 
> thought I 
> >> > would get some feed back on the possibility of shooting a proposal to 
> >> > have 
> >> > embedding static assets into the stdlib. From the looks of it this 
> >> > wouldn't 
> >> > break Go 1 compatibility thou I'm wondering if it would be better to 
> >> > just 
> >> > have this apart of a Go 2 release instead. 
> >> > 
> >> > Any thoughts? 
> >> 
> >> How would this differ from something like 
> >> https://github.com/rakyll/statik , which I think could be invoked via 
> >> go:generate? 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Ian Lance Taylor]

On Mon, Apr 30, 2018 at 12:10 PM, John Unland  wrote:
>
> Don't think so, I think most tools out there have the same basic premise
> behind embedding assets. I think it would be great to have one standard tool
> into the stdlib. Since Go is a language for the web this would align greatly
> with something like this.

I think the place for such a standardized tool would
golang.org/x/tools, along the lines of cmd/stringer which is there
today.

Ian


> On Monday, April 30, 2018 at 1:09:02 PM UTC-5, Ian Lance Taylor wrote:
>>
>> On Mon, Apr 30, 2018 at 7:03 AM, John Unland  wrote:
>> >
>> > Hey everyone I've been mulling over this for a couple of days, thought I
>> > would get some feed back on the possibility of shooting a proposal to
>> > have
>> > embedding static assets into the stdlib. From the looks of it this
>> > wouldn't
>> > break Go 1 compatibility thou I'm wondering if it would be better to
>> > just
>> > have this apart of a Go 2 release instead.
>> >
>> > Any thoughts?
>>
>> How would this differ from something like
>> https://github.com/rakyll/statik , which I think could be invoked via
>> go:generate?
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[John Unland]

Don't think so, I think most tools out there have the same basic premise 
behind embedding assets. I think it would be great to have one standard 
tool into the stdlib. Since Go is a language for the web this would align 
greatly with something like this.

On Monday, April 30, 2018 at 1:09:02 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Apr 30, 2018 at 7:03 AM, John Unland  > wrote: 
> > 
> > Hey everyone I've been mulling over this for a couple of days, thought I 
> > would get some feed back on the possibility of shooting a proposal to 
> have 
> > embedding static assets into the stdlib. From the looks of it this 
> wouldn't 
> > break Go 1 compatibility thou I'm wondering if it would be better to 
> just 
> > have this apart of a Go 2 release instead. 
> > 
> > Any thoughts? 
>
> How would this differ from something like 
> https://github.com/rakyll/statik , which I think could be invoked via 
> go:generate? 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] proposal: embed static assets

[Ian Lance Taylor]

On Mon, Apr 30, 2018 at 7:03 AM, John Unland  wrote:
>
> Hey everyone I've been mulling over this for a couple of days, thought I
> would get some feed back on the possibility of shooting a proposal to have
> embedding static assets into the stdlib. From the looks of it this wouldn't
> break Go 1 compatibility thou I'm wondering if it would be better to just
> have this apart of a Go 2 release instead.
>
> Any thoughts?

How would this differ from something like
https://github.com/rakyll/statik , which I think could be invoked via
go:generate?

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] proposal: embed static assets

[John Unland]

Hey everyone I've been mulling over this for a couple of days, thought I 
would get some feed back on the possibility of shooting a proposal to have 
embedding static assets into the stdlib. From the looks of it this wouldn't 
break Go 1 compatibility thou I'm wondering if it would be better to just 
have this apart of a Go 2 release instead.

Any thoughts? 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.