kevinburke / go-bindata Goto Github PK

Are you open to receive an implementation for net/http.FileSystem for the generated assets? So that it's possible to use http.FileServer?

In this mode we would ignore the in-memory assets and read assets from disk.

I forked this from the original project and now that project has been deleted so it appears like it's been forked from some random other fork.

I'd rather delete the fork but I think the only way to do that is to delete the project and readd it, which I'm not excited about - Homebrew installs releases from here for one thing.

kevinburke/go-html-boilerplate#8

👋 Hello!

It looks like the v4.0.2 release didn't generate the AMD64 binary for Linux. Is that expected?

Thanks!

👋 it looks like the 3.25.0 release was not listed as latest release, just create this issue to confirm if that is intended latest release. Thanks!

relates to Homebrew/homebrew-core#126295

If we send a signal while safefile is in the middle of writing a file to disk, we end up with *.tmp files in the directory which is not good.

It should be easy to compute/retrieve a hash of an asset.

src/assets/bindata.go:29746:53: string literal contains the Unicode format character U+200C, consider using the '\u200c' escape sequence (ST1018)

We should fix this to generate the right escape sequence.

cc @dominikh

We ask the user to give us the package name, we can include it in the returned errors.

We could also add a IsNotExist(err) function for determining whether an error is because a file wasn't present.

Not strictly a necessity for generated code, but it doesn't hurt to fix. The offending line is

var _bintree = &bintree{nil, map[string]*bintree{
	"myfile": &bintree{myFile, map[string]*bintree{}},
}}

This can be simplified to

var _bintree = &bintree{nil, map[string]*bintree{
	"myfile": {myFile, map[string]*bintree{}},
}}

Which is what gofmt -s will do.

Currently, I am using this repo to generate files for swagger. I am tracking the generated files in git. When I re-run generate, even when there are no changes to swagger files, I can see the changes in git status, and the culprit is time in this line:

info := bindataFileInfo{name: "api.swagger.json", size: 20912, mode: os.FileMode(0664), modTime: time.Unix(1632899743, 0)}

Is it possible to disable the time portion, so that I will see the changes in generated files only when there is genuine changes in the asset files?

P.S. Passing -modtime 0 doesn't make any difference.

Edit: It seems passing integer other than 0 works fine. Thanks.

Here is the code.
If my input path is .(aka pwd), and I set -ignore but not -prefix, it would not call filepath.Abs to make . into an abstract path. So I will get entries like a.go, b.go.
However, if I set -prefix, it would call filepath.Abs, so entries are turned into /abs/path/to/a.go, /abs/path/to/b.go.
This different handle may make -ignore not work as intended.
And I raise this issue to check whether this is working by designed. If not, I would be glad to contribute my PR to fix this.

There's another fork that seems to be the canonical now at github.com/go-bindata/go-bindata. Should this one be merged into that fork and then set this up as a mirror to it?

It looks like the version number that's reported via go-bindata --version didn't get updated as part of the 3.18.0 release that resulted from #26. It still reports 3.17.0.

At the top of the file we do

// templates/index.html
// static/photos/style.css

I'm trying to figure out which files take up the most space and it might be helpful to append file sizes to that data.

Do you plan to add Go modules support?

"io/ioutil" has been deprecated since Go 1.16: As of Go 1.16, the same functionality is now provided by package io or package os, and those implementations should be preferred in new code. See the specific function documentation for details. (SA1019)

Hi @kevinburke , very new to golang, so I might totally off-base here. A go application got onto my plate which compiles well for linux/amd64 & Darwin, but for linux/s390x, it is looking for a bindata file like go-bindata-linux-s390x

• how do I create bindata for linux/s390x?
• I downloaded the Source, but not sure what /data files are required.

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.

We should ensure that the assetfs project is compatible with the output from this project.

As README mentioned, the URL https://go.equinox.io/github.com/kevinburke/go-bindata/go-bindata is missing now. So where to get the latest binary?

FYI I've just added this to Homebrew if you feel like mentioning it in your docs @kevinburke
Homebrew/homebrew-core@4aa3404
Homebrew/homebrew-core#24801

I think it'd be nice if you could create a new release that includes 1f34fcd

Hi (great fork by the way) - our build uses go sec if we auto generate code then this causes a problem with the line io.Copy(&buf, gz) in release.go. Gosec flags this as I think an explosion issue.

I don't mind the act of doing the copy(unless it was easy to fix) as we are pretty controlled over what file we run this on but would it be possible to have the #nosec directive.

I am happy enough to raise a PR if needbe. It is perhaps something that would require a deeper look but I thought it worth raising as we incorporate on a pretty stringent CI lint/ sec etc etc setup and it works perfectly but for this one issue.

Thanks
Eoin

I have a bindata.go file - what is the easiest way to "unpack" all the assets back into regular files on disk?

I installed go-bindata with go install github.com/go-bindata/go-bindata/...@latest. Now I have go-bindata.exe in my global Go, but listing help it looks like there is no decompression option.
I guess I should write some simple Go program to uncompress (using RestoreAssets function in bindata.go?). But I've never written anything in Go, so any hints/directions are much appreciated.

This is anti-recommended, and causes spurious failures when tests and run using Go modules because all the source code is checked out read-only ( https://golang.org/ref/mod#module-cache also golang/go#28386).

Failure, observed with read-only testdata:

% go test -bench B .
--- FAIL: BenchmarkBindata
    benchmark_test.go:47: open testdata/assets/sf-fzlmnmzwlrm7hq2x.tmp: permission denied
FAIL
exit status 1
FAIL	github.com/kevinburke/go-bindata	0.793s
FAIL

Or, in a directory containing a go.mod:

go test github.com/kevinburke/go-bindata -bench B -run nope
--- FAIL: BenchmarkBindata
    benchmark_test.go:47: open testdata/assets/sf-jwvtvw26u2y72aov.tmp: permission denied
FAIL
exit status 1
FAIL	github.com/kevinburke/go-bindata	0.635s
FAIL

-run nope was specified above because of problems with other tests; this specific failure concerns running benchmarks, which is how I found this.

The benchmark says a single run generates 16,000 allocations. That's going to be really slow.

Can we do anything to reduce the number of allocations?

The output of go-bindata changes occasionally.

If a project using go-bindata run it on every build and checks in the output files, they have to ensure all contributors use the same version of go-bindata.

When a contributor finds that generated files on their machine come out different from what's checked in, they get confused on whether they did something wrong or the build is broken. Project maintainers could try to overcome the confusion by different means, of course, but it would be very convenient if go-bindata included some a version as part of the header comment in the generated file.

It's probably better to avoid using the release version of the tool, as generated files should have to change with every version, it could be the minor version (if files only change on minor version), or there could be a schema version of sort that has to increment every time a change to the generated code is inevitable.

So, if one has a simple git diff based test to find out whether generated files are up to date, right now they see something like:

diff --git a/pkg/addons/assets.go b/pkg/addons/assets.go
index 0cd5af1a..6aa21c66 100644
--- a/pkg/addons/assets.go
+++ b/pkg/addons/assets.go
@@ -25,7 +25,7 @@ import (
 func bindataRead(data []byte, name string) ([]byte, error) {
        gz, err := gzip.NewReader(bytes.NewBuffer(data))
        if err != nil {
-               return nil, fmt.Errorf("read %q: %v", name, err)
+               return nil, fmt.Errorf("Read %q: %v", name, err)
        }
 
        var buf bytes.Buffer
@@ -33,7 +33,7 @@ func bindataRead(data []byte, name string) ([]byte, error) {
        clErr := gz.Close()
 
        if err != nil {
-               return nil, fmt.Errorf("read %q: %v", name, err)
+               return nil, fmt.Errorf("Read %q: %v", name, err)
        }
        if clErr != nil {
                return nil, err

Instead, they could see this:

diff --git a/pkg/addons/assets.go b/pkg/addons/assets.go
index 0cd5af1a..6aa21c66 100644
--- a/pkg/addons/assets.go
+++ b/pkg/addons/assets.go
@@ -5,1 +5,1 @@ import (
- // go-bindata schema v1 (3.16.x)
+ // go-bindata schema v2 (3.17.x)
@@ -25,7 +25,7 @@ import (
 func bindataRead(data []byte, name string) ([]byte, error) {
        gz, err := gzip.NewReader(bytes.NewBuffer(data))
        if err != nil {
-               return nil, fmt.Errorf("read %q: %v", name, err)
+               return nil, fmt.Errorf("Read %q: %v", name, err)
        }
 
        var buf bytes.Buffer
@@ -33,7 +33,7 @@ func bindataRead(data []byte, name string) ([]byte, error) {
        clErr := gz.Close()
 
        if err != nil {
-               return nil, fmt.Errorf("read %q: %v", name, err)
+               return nil, fmt.Errorf("Read %q: %v", name, err)
        }
        if clErr != nil {
                return nil, err

That would make it much clearer that go-bindata version is key to the change in generated output.

Do you embed the go-bindata program into a standalone package, or do you embed it with other Go source code?

Respond with thumbs up emoji if you embed into a standalone package. Thumbs down if you put other Go source files in the compiled package.

This will help inform library design. Thanks!

This is the mode that makes more sense for reading so let's use it. In the newly released v3.13.0 release.

Previously:

os.FileMode(420)

is now:

os.FileMode(0644)

The functionality is exactly the same.

If someone wants to install from source using 1.18, they get:

$ go get -u github.com/kevinburke/go-bindata/...
go: go.mod file not found in current directory or any parent directory.
        'go get' is no longer supported outside a module.
        To build and install a command, use 'go install' with a version,
        like 'go install example.com/cmd@latest'
        For more information, see https://golang.org/doc/go-get-install-deprecation
        or run 'go help get' or 'go help install'.

This is what's given in the README.

A fix will be given in a PR momentarily. Thanks for maintaining this awesome tool 😄

We use gzip compression but we should be able to verify at compile time that the string in our file is valid, and remove the error from the method signature.