expose whether build in debug mode

[josharian]

Use case: I have go templates as assets. In debug mode, I want to re-parse the template every time, in case it has changed. In non-debug mode, I want to parse only once. This decision and the code around it can't be done in go-bindata (unless you want to add template parsing helpers into the generated code). So I propose we add a AssetDebug() bool function or the like to the generated code.

[kevinburke]

Sure... why a function instead of a constant, is the idea that someone else could change a constant?

[kevinburke]

I suspect this use case might come up again so it might be good to either have a BuildInfo() struct or function that we can add e.g. compile time etc. to, as well as debug/non-debug.

[josharian]

A constant seems fine. I was just not thinking clearly.

[josharian]

Thanks for the fix! I was going to send a PR but delighted you beat me to it.

One thought: should it be called AssetDebug or the like? Debug might conflict with existing identifiers in peoples packages.

[kevinburke]

It would be guarded by the package import path right? I don’t think it’s possible to create arbitrary Upper case variable names right now by getting creative with file names... maybe I’m not understanding

On Mon, May 18, 2020 at 09:12 Josh Bleecher Snyder ***@***.***> wrote: Thanks for the fix! I was going to send a PR but delighted you beat me to it. One thought: should it be called AssetDebug or the like? Debug might conflict with existing identifiers in peoples packages. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZEI6FTFUXHLX7FEUR5N3RSFM5HANCNFSM4NDOJZGA> .

-- Kevin Burke phone: 925-271-7005 | kevin.burke.dev

[kevinburke]

Ohhh.. you don’t use this as a standalone package you embed it into a package that has other files along with it. Let me think about it.

On Mon, May 18, 2020 at 09:56 Kevin Burke ***@***.***> wrote: It would be guarded by the package import path right? I don’t think it’s possible to create arbitrary Upper case variable names right now by getting creative with file names... maybe I’m not understanding On Mon, May 18, 2020 at 09:12 Josh Bleecher Snyder < ***@***.***> wrote: > Thanks for the fix! I was going to send a PR but delighted you beat me to > it. > > One thought: should it be called AssetDebug or the like? Debug might > conflict with existing identifiers in peoples packages. > > — > You are receiving this because you modified the open/close state. > > > Reply to this email directly, view it on GitHub > <#31 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABZEI6FTFUXHLX7FEUR5N3RSFM5HANCNFSM4NDOJZGA> > . > -- Kevin Burke phone: 925-271-7005 | kevin.burke.dev

-- Kevin Burke phone: 925-271-7005 | kevin.burke.dev

[josharian]

I guess it depends on whether people generate code into a separate package or directly into their own. Since the default package path is main, not asset, I assume that that is common. Maybe I’m wrong though.