GithubHelp home page GithubHelp logo

geertjohan / go.rice Goto Github PK

View Code? Open in Web Editor NEW
2.4K 58.0 185.0 267 KB

go.rice is a Go package that makes working with resources such as html,js,css,images,templates, etc very easy.

License: BSD 2-Clause "Simplified" License

Go 100.00%

go.rice's Introduction

go.rice

Build Status Godoc

go.rice is a Go package that makes working with resources such as html,js,css,images and templates easy. During development go.rice will load required files directly from disk. Upon deployment it's easy to add all resource files to a executable using the rice tool, without changing the source code for your package. go.rice provides methods to add resources to a binary in different scenarios.

What does it do

The first thing go.rice does is finding the correct absolute path for your resource files. Say you are executing a binary in your home directory, but your html-files are in $GOPATH/src/yourApplication/html-files. go.rice will lookup the correct path for that directory (relative to the location of yourApplication). All you have to do is include the resources using rice.FindBox("html-files").

This works fine when the source is available to the machine executing the binary, which is the case when installing the executable with go get or go install. But it does not work when you wish to provide a single binary without source. This is where the rice tool comes in. It analyses source code and finds call's to rice.FindBox(..). Then it adds the required directories to the executable binary, There are two strategies to do this. You can 'embed' the assets by generating go source code and then compile them into the executable binary, or you can 'append' the assets to the executable binary after compiling. In both cases the rice.FindBox(..) call detects the embedded or appended resources and load those, instead of looking up files from disk.

Installation

Use go install to install the package the rice tool.

go install github.com/GeertJohan/go.rice@latest
go install github.com/GeertJohan/go.rice/rice@latest

Package usage

Import the package: import "github.com/GeertJohan/go.rice"

Serving a static content folder over HTTP with a rice Box:

http.Handle("/", http.FileServer(rice.MustFindBox("http-files").HTTPBox()))
http.ListenAndServe(":8080", nil)

Serve a static content folder over HTTP at a non-root location:

box := rice.MustFindBox("cssfiles")
cssFileServer := http.StripPrefix("/css/", http.FileServer(box.HTTPBox()))
http.Handle("/css/", cssFileServer)
http.ListenAndServe(":8080", nil)

Note the trailing slash in /css/ in both the call to http.StripPrefix and http.Handle.

Loading a template:

// find a rice.Box
templateBox, err := rice.FindBox("example-templates")
if err != nil {
	log.Fatal(err)
}
// get file contents as string
templateString, err := templateBox.String("message.tmpl")
if err != nil {
	log.Fatal(err)
}
// parse and execute the template
tmplMessage, err := template.New("message").Parse(templateString)
if err != nil {
	log.Fatal(err)
}
tmplMessage.Execute(os.Stdout, map[string]string{"Message": "Hello, world!"})

Never call FindBox() or MustFindBox() from an init() function, as there is no guarantee the boxes are loaded at that time.

Calling FindBox and MustFindBox

Always call FindBox() or MustFindBox() with string literals e.g. FindBox("example"). Do not use string constants or variables. This will prevent the rice tool to fail with error Error: found call to rice.FindBox, but argument must be a string literal..

Tool usage

The rice tool lets you add the resources to a binary executable so the files are not loaded from the filesystem anymore. This creates a 'standalone' executable. There are multiple strategies to add the resources and assets to a binary, each has pro's and con's but all will work without requiring changes to the way you load the resources.

rice embed-go: Embed resources by generating Go source code

Execute this method before building. It generates a single Go source file called rice-box.go for each package. The generated go file contains all assets. The Go tool compiles this into the binary.

The downside with this option is that the generated go source file can become large, which may slow down compilation and requires more memory to compile.

Execute the following commands:

rice embed-go
go build

A Note on Symbolic Links: embed-go uses the os.Walk function from the standard library. The os.Walk function does not follow symbolic links. When creating a box, be aware that any symbolic links inside your box's directory are not followed. When the box itself is a symbolic link, the rice tool resolves its actual location before adding the contents.

rice append: Append resources to executable as zip file

This method changes an already built executable. It appends the resources as zip file to the binary. It makes compilation a lot faster. Using the append method works great for adding large assets to an executable binary.

A downside for appending is that it does not provide a working Seek method.

Run the following commands to create a standalone executable.

go build -o example
rice append --exec example

Help information

Run rice --help for information about all flags and subcommands.

You can use the --help flag on each sub-command. For example: rice append --help.

Order of precedence

When opening a new box, the rice.FindBox(..) tries to locate the resources in the following order:

  • embedded (generated as rice-box.go)
  • appended (appended to the binary executable after compiling)
  • 'live' from filesystem

License

This project is licensed under a Simplified BSD license. Please read the LICENSE file.

Package documentation

You will find package documentation at godoc.org/github.com/GeertJohan/go.rice.

go.rice's People

Contributors

3onyc avatar abourget avatar alecthomas avatar antonienko avatar avi-turetsky avatar bfallik avatar cortesi avatar daver76 avatar geertjohan avatar gwitmond avatar iand avatar jwtracy avatar mattn avatar michaelvlaar avatar mtiller avatar mtojek avatar nkovacs avatar nwolff avatar paulmaddox avatar pzeinlinger avatar renekroon avatar sethp avatar shawnps avatar steveoc64 avatar tgulacsi avatar tronical avatar ulfurinn avatar urandom2 avatar vallezw avatar vincent-petithory avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

go.rice's Issues

Weird error on upgrading Go 1.3.1 to Go 1.3.3

Hi Folks,

I have upgraded the Go version from 1.3.1 to 1.3.3 in my machine and then I was getting following error for go.rice.

$ go get github.com/GeertJohan/go.rice/rice
# github.com/GeertJohan/go.rice/rice
../../../../_work/gocode/src/github.com/GeertJohan/go.rice/rice/append.go:15: import /home/budhram/_work/gocode/pkg/linux_amd64/github.com/daaku/go.zipexe.a: object is [linux amd64 go1.3.1 X:precisestack] expected [linux amd64 go1.3.3 X:precisestack]

What could be issue?

Finding boxes in the sub-packages

I know it says so in the TODO section in the README, but go.rice needs to support finding boxes in packages.

I have an local webserver app that is using rice to store resources, but it doesn't work for the packages I import, even when these packages use rice embed-go strategy to store their assets. That's really limiting my ability to use rice, and I guess I'm not the only one with this problem.

I'm creating this issue to track the progress. I'm would like to work on this and would appreciate any pointers on where should I start.

rice append when rice.MustFindBox is in package

Hello,

thank you for great package.

Could you make rice tool recursive? So that it could embed resources if rice.MustFindBox is called in package in subdirectory and not in main program.

For example I would like to change https://github.com/pksunkara/alpaca so that it will use go.rice:
https://github.com/matrixik/alpaca/blob/master/alpaca/template.go#L11
But it's package and not main program. It's working fine when I just build main program but when I try to run rice append --exec alpaca.exe I got error:

no calls to rice.FindBox() found
Error setting zip offset: exit status 13

Or maybe there is some way for it to work that I don't know?

Best regards,
Dobrosław Żybort

Fails to locate box when cross-compiling in go 1.5

When cross compiling using go 1.5 the resultant binary fails with:

panic: could not locate box "../assets/templates"

goroutine 1 [running]:
github.com/GeertJohan/go%2erice.MustFindBox(0x820abdfc0, 0x13, 0x9)
    /go/src/github.com/GeertJohan/go.rice/box.go:110 +0x9a

This is true for multiple target architectures. I've verified that it works fine when compiling natively on multiple targets.

I'm using commit ada95a01c963696fb73320ee662195af68be81ae of this repository; this is the tip of master branch.

I'm cross compiling with e.g. GOOS=linux GOARCH=arm GOARM=7 go build main.go

Do you know what would be different about cross compiling vs compiling natively?

rice 2.0: move away from source parsing and use a Ricefile?

"Rice 2.0? But 1.0 hasn't even been released yet!?"
Correct. Please see #48 about that.

Dropping .go file source parsing
I've been thinking about this for a while now. The parsing of go source is a nice feature, but doesn't always work as expected:

const boxName = `someBox`
rice.FindBox(boxName) // will work in 'live' mode, but rice tool won't find this box so it isn't embedded/appended.

This can be solved by moving the configuration of boxes to a Ricefile; a config file in some human-readable format such as yaml. This also allows us to define more configuration parameters per box such as:

  • strategy: embed vs append (embed one box, append the other).
  • path different than box name

Ricefile should be located in main package for the binary, but can include boxes used in sub-packages.
Ricefile import other Ricefiles based on import path? This could make defining resources in packages a feasible reality.

This issue is a work in progress..

Getting list of filenames in the box

A method like (*File).Readdirnames(n int) ([]string, error) would be helpful:

box := rice.MustFindBox("html")
names, _ := box.Readdirnames(-1)
for _, name := range names {
    tmpl, err := template.New(name).Parse(box.MustString(name))
    ...
}

I can send a PR once details are agreed upon.

embedding fails with symlink

Thanks for this tool, it works great. Only issue I came across is with symlinks - although fetching from filesytem works, embedding fails:

error reading file content while walking box: read /path/static: is a directory

Vendoring binaries

I use go.rice to embed static files into my binaries and would like to vendor the rice main package.

I already did this using vendor add github.com/GeertJohan/go.rice/rice and the package was successfully vendored, however, the package status is listed as "unused".

I figure this is because the package is not imported anywhere, nor could it be.

Would it perhaps be a good idea to consider packages that are named "main" as internal and pull their dependencies as well when vendoring them?

embedsyso supposed to work on Windos TM?

Hi, I am using embedsyso for quite a while now to embed the web frontend of my tool. So far it worked perfectly.
Now I had to use my tool on Windows. Everything works fine besides the frontend.
I guess my question is: "is this supposed to work on windows?"

2nd thing I like to know is if I can do something - I mean beside the obvious fix it and submit a PR?

Yeah, I should probably mention two things... I already tried to get rid of the Unix path separator to avoid the Windows TM backslash extravagance. My attempt to resolve this was to write a specialized embedsyso boxer (https://github.com/finklabs/embedsyso).

Here the console output of panic:
panic: could not locate box "../web"

goroutine 1 [running]:
github.com/GeertJohan/go%2erice.MustFindBox(0x808348, 0x6, 0x0)
/home/mark/devel/gocode/src/github.com/GeertJohan/go.rice/box.go:110 +0x82
github.com/finklabs/GoGrinder/gogrinder.(*TestServer).Router(0x1274e180, 0x1274e180)
/home/mark/devel/gocode/src/github.com/finklabs/GoGrinder/gogrinder/server.go:153 +0xae

Cannot specify build flags to detect correct file for `rice embed-go`

I have two files:

js_asset_prod.go:

// +build production

package server

import (
    "github.com/GeertJohan/go.rice"
)

var javascriptAssetRiceBox = rice.MustFindBox("./js/prod").HTTPBox() // <--- prod path

and js_asset_dev.go:

// +build !production

package server

import (
    "github.com/GeertJohan/go.rice"
)

var javascriptAssetRiceBox = rice.MustFindBox("./js/dev").HTTPBox() // <-- dev path

And when I run rice -v -i ./server/ embed-go I get output like:

2015/05/06 23:50:17 skipping file "~/server/js-dev.rice-box.go"
2015/05/06 23:50:17 scanning file "~/server/js_asset_dev.go"
2015/05/06 23:50:17     found box "js/dev"
2015/05/06 23:50:17 scanning file "~/server/server.go"
2015/05/06 23:50:17
2015/05/06 23:50:17 embedding box 'js/dev'
2015/05/06 23:50:17     to file js-dev.rice-box.go
2015/05/06 23:50:17     includes dir: ''
2015/05/06 23:50:17
2015/05/06 23:50:17 rice finished successfully

It appears that rice does not recognize js_asset_prod.go because it has an opt-in build flag, and in go.rice/flags.go, it uses build.ImportDir which does not support adding build flags (and the rice CLI does not support adding build flags either).

rice embed error

error when trying the rice example on a Windows machine:
2014/02/28 16:11:17 error writing embedded box to file (template execute): template: embeddedBox:23:26: executing "embeddedBox" at <.Identifier>: nil pointer evaluating *main.fileDataType.Identifier

BTW:I'm using Windows Amd64 go1.2

rice append doesn't append compressed zip contents, but plain text?

Appending two boxes (templates and assets folder), I can inspect the binary files and realize that the appended data is not compressed at all:

--- ping-dashboard-orig.hex     2016-10-03 15:11:35.050537200 +0200
+++ ping-dashboard.hex  2016-10-03 15:08:22.578537200 +0200
@@ -418688,3 +418688,8226 @@
 06637f0: 0000 0000 0000 0000 1031 6600 0000 0000  .........1f.....
 0663800: d000 0000 0000 0000 0000 0000 0000 0000  ................
 0663810: 0100 0000 0000 0000 0000 0000 0000 0000  ................
+0663820: 504b 0304 1400 0000 0000 0000 0000 0000  PK..............
+0663830: 0000 0000 0000 0000 0000 0900 0000 7465  ..............te
+0663840: 6d70 6c61 7465 7350 4b03 0414 0000 0000  mplatesPK.......
+0663850: 0034 5a43 49e5 6bc7 bb73 0e00 0073 0e00  .4ZCI.k..s...s..
+0663860: 0013 0000 0074 656d 706c 6174 6573 2f6d  .....templates/m
+0663870: 6169 6e2e 6874 6d6c 3c21 444f 4354 5950  ain.html<!DOCTYP
+0663880: 4520 6874 6d6c 3e0a 3c68 6561 643e 0a3c  E html>.<head>.<
+0663890: 6d65 7461 2063 6861 7273 6574 3d22 7574  meta charset="ut
+06638a0: 662d 3822 3e0a 3c6c 696e 6b20 7265 6c3d  f-8">.<link rel=
+06638b0: 2273 7479 6c65 7368 6565 7422 2074 7970  "stylesheet" typ
+06638c0: 653d 2274 6578 742f 6373 7322 2068 7265  e="text/css" hre
+06638d0: 663d 222f 2f66 6f6e 7473 2e67 6f6f 676c  f="//fonts.googl
+06638e0: 6561 7069 732e 636f 6d2f 6373 733f 6661  eapis.com/css?fa
+06638f0: 6d69 6c79 3d4f 7065 6e2b 5361 6e73 2220  mily=Open+Sans"
+0663900: 2f3e 0a3c 7374 796c 6520 7479 7065 3d22  />.<style type="
+0663910: 7465 7874 2f63 7373 2220 6d65 6469 613d  text/css" media=
+0663920: 2273 6372 6565 6e22 3e0a 0962 6f64 7920  "screen">..body
+0663930: 7b0a 0909 6261 636b 6772 6f75 6e64 3a20  {...background:
+0663940: 2330 3030 3b0a 0909 636f 6c6f 723a 2023  #000;...color: #
+0663950: 6666 663b 0a09 7d0a 092a 207b 0a09 0966  fff;..}

I'm expecting the zip file would be compressed which doesn't seem to be the case...

embed-go performance and memory usage

I've optimized embed-go a bit. The trick is that I don't write the file contents into the source code, just a placeholder, format the code with the placeholders, then use fasttemplate to replace the placeholders with the contents of the files, streaming it directly from the original files to the destination go file.

This means the files are never held in memory completely, so memory usage is much lower.
It also avoids running gofmt on a very large source code, which speeds up things a bit and also lowers memory usage.

Since gofmt doesn't always align struct values depending on their length, I had to add an empty line to make sure the code is always correctly formatted.

I also had to copy the code behind strconv.Quote, unfortunately the public API was not good enough, and performance was pretty bad with it.

With a fairly large box of 387 files, mostly javascript, the numbers are:
before:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.18
Maximum resident set size (kbytes): 264668
after:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.56
Maximum resident set size (kbytes): 9144

With a single, 80Mb file:
before:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:06.59
Maximum resident set size (kbytes): 2213800
after:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.03
Maximum resident set size (kbytes): 10192

I haven't tested it thoroughly and I still need to escape the fasttemplate placeholders in case they show up somewhere else in the generated code.

The code is in this branch: https://github.com/nkovacs/go.rice/tree/fasttemplate

What do you think?

box lists its contents but should not

thanks for sharing this code. Is is very helpful.

Not sure if it matters, I used "rice embed-syso" to create the box.
There is one thing that is a little bit disturbing for me. Every time I run the code the box prints out all the contents to the console. I have not yet found out why it does that. I think the expected behavior for packages is to "shut up" or return an error?

This is how I use the box:

box := rice.MustFindBox("web")
appFileServer := http.FileServer(box.HTTPBox())

Any chance that this configurable?

suggested optimization: string literal embedding

Take a look at dsymonds/goembed#1 — using string literals speeds up compilation massively. I’ll send another PR on goembed soon to reduce the size of the generated string literal.

Using the same techniques as the goembed PRs should do away with the resource blow-up you mention in your README.md.

exclude option for rice

Can you add a exclude option please so I can specify which files or directories should not be in the *.rice-box.go

Allow controlling box lookup order.

I'd like to reverse the box search path:

  • check on disk and use if available
  • check for embedded boxes as fallback

This would allow two things:
(1) Developers running with embedded boxes to the build system doesn't differentiate.
(2) Possibility to temporarily "patch" a running server by overriding boxes from disk.

Serving multiple sub-directories at root level

I want to serve the following static folder. However, I would like, e.g., the files foo.json and all.html to be available via /foo.json and /all.html. Is there currently a way to do this with Rice?

[jess@localhost assets]$ tree -L 2
.
├── frontend
│   └── foo.json
└── iframes
    ├── all.html
    ├── css
    ├── img
    ├── js
    └── lib

6 directories, 2 files

If not, I propose implementing a way to "join" boxes and create a new box. If you're on-board, I would be happy to implement this myself.

Thanks!

High Memory Usage

After running rice embed-go I get 33M *.rice-box.go file. When I run go build after that, I can't get it to build because RAM shoots up to more than 14.5GB. I've tried increasing my swap, but it keeps maxing it out. Any idea what's happening?

feature request: Support exclude(ignore) using .riceignore

Similar issues: #80 #37

go.rice does not support excluding files and this result in huge binary if you have folders like node_modules, and due to the way rice find boxes (related #47 ), it's hard to specify different box location for same box during development and production. So similar to git and docker, which has .gitignore and .dockeringore, a .riceignore file can be introduced to make rice more flexible without
changing how rice find boxes.

The implementation in docker for dockerignore can be a good start, also there is a dockerignore library

I have already tried it in my own fork in this commit. It works for append zip only, and use the library mentioned above, it works for this small project. Though the behavior is not exactly same as gitingore and only .riceignore file at box root is supported.

I can make a pull request if go.rice is still under development. Thanks~

Can't serve files from outside /

Using example.go from this repo as is works just fine. If I change:

    http.Handle("/", http.FileServer(box.HTTPBox()))

to

    http.Handle("/files", http.FileServer(box.HTTPBox()))

(or "/files/" with a trailing slash), everything 404s at any reasonable URL to test, the directory indexes don't work and so forth. I tried /file.txt, /files, /files/, /files/file.txt and several other variations. Am I instantiating something wrong, or is there a path issue here?

Using rice.Config rice tool can't find calls

Based on the example.go file

package main

import (
    "fmt"
    "github.com/gutenye/go.rice"
)

func main() {
    r := rice.Config{
        LocateOrder: []rice.LocateMethod{rice.LocateFS, rice.LocateEmbedded},
    }

    _, _ = r.FindBox("www")
}

run $GOPATH/bin/rice -v embed-go

2015/05/14 10:21:19 using pwd as import path
2015/05/14 10:21:19 using import paths: [gothing]
2015/05/14 10:21:19 scanning file "/Development/Go/gothing/src/gothing/main.go"
no calls to rice.FindBox() found
2015/05/14 10:21:19
2015/05/14 10:21:19 rice finished successfully

rice tool fails to build

I think this just started happening within the last hour or so since we go get go.rice in our build server and all was fine this morning. Getting the following build error now:

# github.com/GeertJohan/go.rice/rice
../../../github.com/GeertJohan/go.rice/rice/append.go:59: undefined: zipexe
../../../github.com/GeertJohan/go.rice/rice/identifier.go:5: undefined: incremental

Release rice v1 through gopkg.in

  • Move to go-rice organization.
  • Create v1 branch, release through gopkg.in
  • Fork go-rice/rice to GeertJohan/rice, GeertJohan/rice/master tracks v1 with edited README pointing to go-rice/rice
  • Update go-rice/rice README with versioning details, use master as development branch, same as go-gorp.

Feature: Append zip files defined in non-main packages.

I'd like to use go.rice in non-main packages and then append zip files to provide the boxes. My main package has no calls to go.rice.

I'm happy to manually define the box names (e.g. rice append --name="client" --dir="path/to/client" bin/prog, or provide a manifest file) if they cannot be determined automatically.

Use (*zip.Writer).SetOffset()

Executing zip -A can be dropped in favor of using the archive/zip SetOffset functionality. This will only work for go1.5 so support for other versions will be dropped at that point.

Add a Way to Retrive List of Files and Directories

We are using rice at drone/drone. There are places where we have to process templates. We load the templates from the box and parse them in the init function. To accomplish this we need a massive list of files in the source code. It would be great if we can avoid this list. Would it be if I implemented a way to get a list of embedded file names and possibly directory names? Does anyone have any suggestions about the implementation?

func(b *Box) Files() []string {
  //...
}

func(b *Box) Dirs() []string {
  //...
}

golint complains about generated code

golint mytool
mytool/resources.rice-box.go:11:2: don't use underscores in Go names; var file_2 should be file2
mytool/resources.rice-box.go:18:2: don't use underscores in Go names; var dir_1 should be dir1

Append work on windows

Hi everybody,

I have try to make an append on windows and it's working.

package main
import (
	"fmt"
	"github.com/GeertJohan/go.rice"
)

func main() {
	assetsBox, err := rice.FindBox("assets/")
	if err != nil {
		panic("oups")
	}
	content, _ := assetsBox.String("plop.txt")
	fmt.Println(content)
}

The directory structure

- /
   - main.go
   - Assets/
      - plop.txt

And I have try with that command

go build
rice append /exec app.exe

#### WARNING ! ####
rice append` is known not to work under windows because the `zip` command is not available. Please let me know if you got this to work (and how).

When I execute the binary (in place, in a different folder, in different computer) it show the content of plop.txt file like expected.

So it's seems to work

PS: I'm under windows 10 without zip available in command line

drone error

hi, could you please see this error for me? thanks!

root@drone:/go/src/drone/bin# drone
panic: box name contains illegal dot (.) character

goroutine 1 [running]:
runtime.panic(0x87bc00, 0xc21000ad40)
/usr/local/go/src/pkg/runtime/panic.c:266 +0xb6
github.com/GeertJohan/go%2erice.MustFindBox(0x97dd10, 0x17, 0x9)
/go/src/github.com/GeertJohan/go.rice/box.go:86 +0x71
github.com/drone/drone/pkg/template.init·1()
/go/src/github.com/drone/drone/pkg/template/template.go:97 +0x159
github.com/drone/drone/pkg/template.init()
/go/src/github.com/drone/drone/pkg/template/template.go:178 +0xbb
github.com/drone/drone/pkg/mail.init()
/go/src/github.com/drone/drone/pkg/mail/mail.go:142 +0x3d
github.com/drone/drone/pkg/plugin/notify.init()
/go/src/github.com/drone/drone/pkg/plugin/notify/zapier.go:1 +0x65
github.com/drone/drone/pkg/build/script.init()
/go/src/github.com/drone/drone/pkg/build/script/script.go:150 +0x42
main.init()
/go/src/github.com/drone/drone/cmd/drone/util.go:90 +0x54

Infinite loop with File.Readdir()

Edit: cleaned up the whole issue...

The documentation for os.File.Readdir(n) states that when n > 0, Readdir() must return a io.EOF at the end of the directory.
rice.File.Readdir() doesn't comform to this behavior, for appended files and dirs, and so we will enter an infinite loop in https://golang.org/src/net/http/fs.go#L70 when we try to serve appended files with http.FileServer and rice.box.HTTPBox().

I'm afraid that rice.File.Readdir() needs to be rewritten so it instead will work over multiple calls (for example: first call returns all files/dirs in current dir, second call returns io.EOF to end the loop). But that means it needs to save some kind of state and shit, so it would be a pretty big change...
Edit: Nvm, I finally noticed you already got it figured out, for embedded files at least.

"no calls to rice.FindBox() found" when using const for directory

Hi,
when using const for directories to embed, like this:

package main

import (
    "fmt"

    "github.com/GeertJohan/go.rice"
)

const weirdTmp = "/tmp/weird"

func main() {
    constDir := rice.MustFindBox(weirdTmp)
    fmt.Println("constDir:", constDir)
}

This happens:

[cryptix@planc /tmp/tmp] rice -v embed-go
2014/07/24 11:10:04 using pwd as import path
2014/07/24 11:10:04 using import path: .
2014/07/24 11:10:04 scanning file "/tmp/tmp/repro.go"
no calls to rice.FindBox() found
2014/07/24 11:10:04 
2014/07/24 11:10:04 rice finished successfully

While this works as expected:

package main

import (
    "fmt"

    "github.com/GeertJohan/go.rice"
)

func main() {
    constDir := rice.MustFindBox("/tmp/weird")
    fmt.Println(dir:", constDir)
}

Box isn't embedded if its name is the same than the package

A rice box isn't found in the embedded boxes map if it has the same name than its parent package.

I haven't figured what's the cause.

.
├── foobar
    ├── blah.go
    ├── foobar
    │   ├── file1
    │   ├── file2
    │   └── file3
    ├── foobard
    │   └── main.go
    └── foobar.rice-box.go

blah.go:

package foobar

import (
    "fmt"
    "github.com/GeertJohan/go.rice"
    "github.com/GeertJohan/go.rice/embedded"
)

func init() {
    _ = rice.MustFindBox("foobar")
    if _, ok := embedded.EmbeddedBoxes["foobar"]; !ok {
        fmt.Printf("no %q box embedded\n", "foobar")
    } else {
        fmt.Printf("%q embedded box found\n", "foobar")
    }
}

foobard.go:

package main

import (
    _ "github.com/vincent-petithory/foobar"
)

func main() {

}

Running main:

$ ./foobard
no "foobar" box embedded

"rice embed" command finds boxes that only exist in comments

If I create a source .go file containing the following two lines:

//http.Handle("/files/", http.StripPrefix("/files/", http.FileServer(rice.MustFindBox("./").HTTPBox())))
http.Handle("/subdirectory/", http.StripPrefix("/subdirectory/", http.FileServer(rice.MustFindBox("subdirectory/").HTTPBox())))

the verbose output shows that all the files in "./" are included in the box, even though that Box is commented out. If I remove the commented line, "rice embed" creates a compiled file of only the correct items. I don't believe commented lines should be included in the embed generation.

Different paths for embedded/appended files

Hello.
So when I use Walk() I get different path names depending on if I have embedded/appended the files, to the compiled binary, or not. Example code:

    templatebox := rice.MustFindBox("templates")
    templates := template.New("ServerTemplates")
    templatebox.Walk("/", func(p string, i os.FileInfo, e error) error {
            if i.IsDir() {
                    return nil
            }
            s, e := templatebox.String(p)
            if e != nil {
                    log.Fatalf("Failed to load template: %s\n%s\n", p, e)
            }
            template.Must(templates.New(p).Parse(s))
            return nil
    })
    fmt.Println("Loaded templates:")
    for _, t := range templates.Templates() {
            fmt.Println(t.Name())
    }

Normal output is something like:

base.html
index.html

But when I embedd/append I get:

/base.html
/index.html

Took a while for me to notice that difference when my app broke, since it can't load files prefixed with /.
It's easily solved by calling Walk("", ... instead, but thought I should report this bug anyway. I guess it's an oversight in readDirNames().

Mixed file storage

Say I have a box that was built with

box/test.html

I've built my binary, and I've got

    rice := rice.Config{
        LocateOrder: []rice.LocateMethod{rice.LocateFS, rice.LocateEmbedded},
    }

    box, _ := rice.FindBox("box")

    http.Handle("/", http.FileServer(box.HTTPBox())
    go func()
        _ = http.ListenAndServe(":8080", nil)
    }()

    select {}

I can call localhost:8080/test.html just fine
but if I create a directory 'box' and add 'test2.html' to it (and restart the binary)
I can no longer call localhost:8080/test.html

Walk is not able find the path

I am using walk as below to get all the files from the box root, it fails with an error message lstat emails/: no such file or directory.

box := rice.MustFindBox("emails")
box.Walk("", func(path string, info os.FileInfo, err error)

Looking at the code, I found in filepath.Walk call it is using b.name, shouldn't it be absolutePath as that worked for me.

https://github.com/GeertJohan/go.rice/blob/master/walk.go#L29
https://github.com/GeertJohan/go.rice/blob/master/walk.go#L32

@PaulMaddox
@GeertJohan

embed-go filename generation breaks for relative paths

File names for embedded boxes are generated with the following code:

boxFilename := strings.Replace(boxname, "/", "-", -1)
boxFilename = strings.Replace(boxFilename, "..", "back", -1)
boxFilename = boxFilename + `.rice-box.go`

This breaks for relative paths. For instance, the path "./static" will become ".-static.rice-box.go". Note the leading period. Hidden files are ignored by go build, and the box is not included in the binary. The method also breaks in a variety of rare corner cases, like the presence of directories named "back".

This problem is a complicating factor in issue #66 - the example I gave there is actually this bug, not a cross-compilation issue.

I have a pull request inbound that fixes this problem.

arm support

Hi,

is arm architecture supported? I get could not locate box "..." on a rasberry pi. On other arch works fine.

Thanks

go.rice vs. go test -coverprofile

Hi,

I've encountered a problem combining go.rice with go's test coverage tool:

$ go test datastore
ok      datastore   0.028s
$ go test -coverprofile=foo datastore
panic: stat datastore/_test/_obj_test/sql: no such file or directory

goroutine 16 [running]:
runtime.panic(0x3d58c0, 0xc208209ad0)
    /usr/local/Cellar/go/1.3beta1/libexec/src/pkg/runtime/panic.c:279 +0xf5
github.com/GeertJohan/go%2erice.MustFindBox(0x484db0, 0x3, 0xc2081a29b0)
    /Users/bfallik/sandbox/gillnet/go/src/_vendor/src/github.com/GeertJohan/go.rice/box.go:81 +0x6c
datastore.init()
    datastore/_test/_obj_test/datastore.go:17 +0xec
main.init()
    datastore/_test/_testmain.go:206 +0x43
...
FAIL    datastore   0.027s

I know that the cover tool rewrites the sources and runs them from another directory so I can imagine why this would fail for local files. However the tests still fail even when I use 'rice embed' to generate the Go sources containing the data.

By passing the -work flag to the go tools I can muck around with the artifacts, and using 'strings' it looks like the embedded files are part of the binary so I can't figure out why MustFindBox() can't find them.

Any ideas? Is there a recommended way to debug/inspect a binary to see which boxes are embedded?

Thanks,
brian

ignore option missing

Here's how it works with both go-bindata and go-bindata-assetfs:

go-bindata-assetfs -ignore=\.DS_Store

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.