Package is a program, not an importable package

[scottjbarr]

Fails when running against this file...

I've created package foo, and have the following file main.go

package main

import (
    "fmt"
)

type Foo struct {
    Name string
}

func main() {
    f := Foo{Name: "Bar"}
    fmt.Printf("%+v\n", f)
}

Output

$ easyjson -all main.go 
/var/folders/wj/ggsd2sgs2b1_vnplhkcv6g0jk5xz5m/T/easyjson715726581.go:8:3: import "github.com/scottjbarr/foo" is a program, not an importable package
Bootstrap failed: exit status 1

A file called main_easyjson.go with the following content is created

package  main

import (
  "github.com/mailru/easyjson/jwriter"
  "github.com/mailru/easyjson/jlexer"
)
func (* Foo ) MarshalJSON() ([]byte, error) { return nil, nil }
func (* Foo ) UnmarshalJSON([]byte) error { return nil }
func (* Foo ) MarshalEasyJSON(w *jwriter.Writer) {}
func (* Foo ) UnmarshalEasyJSON(l *jlexer.Lexer) {}

• Also, the output file is not gofmt'ed.

[vstarodub]

The issue is that bootstrapping code needs to import the package to do reflection on required structs and this doesn't quite work with main package.

I'll look into the options to make this case work.

As for gofmt, does this cause any trouble? The only case I can think of is when you edit it and gofmt will be run automatically, but it's generally a bad practice to manually edit an autogenerated file.

[scottjbarr]

Ah, got it.

Yes, it would be bad to edit a generated file. For that reason I think it is worth writing a properly gofmt'ed file. It will play nicely for those that do gofmt checks in their build process.

[ernado]

And it will play nicely for those who use pre-commit git hooks with gofmt too.

[vstarodub]

That's perfectly reasonable. I just wanted a use-case to be sure what scenario I am fixing. I've added 'gofmt -w' invocation, see #3.

Haven't gotten to fixing the main package yet, though.

[james-lawrence]

you could avoid the whole issue likely by using the AST packages instead of creating a executable and using reflection. would also make it possible to regenerate the json methods when you remove a field from a structure without having to delete the easyjson file.

[vstarodub]

@james-lawrence Using AST would also be quite fast to generate. That's exactly what I tried doing at first. Unfortunately the code turned out to be more complex than I was willing to support. Maybe I was just using it the wrong way.

On the issue: it seems to be a rather rare scenario, so I didn't get to it yet. I'll have some time to experiment with it over this weekend, looks like it won't be too hard to fix.

[elwinar]

I'm having this problem too, on a small enough package that I don't want to split the pair of structs I need to play with to another package. Any news ?

[kmansoft]

Any news on the AST parser approach?

The use case is as mentioned above by @elwinar - sometimes it's convenient to keep your structs in same source tree and not split into a separate package just because of EasyJSON.

[TheSilvus]

This should probably be noted in the Readme (for now?). It is a limitation of the library and will confuse people who try to use the library after reading through it.

[kmansoft]

@TheSilvus I'm just saying that it would be nice to be able to parse local files (as opposed to having to reference external compile-able packages), which means taking the AST approach to generating metadata. I know this was in the plans at some point, but no actual progress.

Are you saying that the plans have changed, and this definitely won't be implemented?

[TheSilvus]

@kmansoft Probably didn't explain myself well, sorry. I've only used this library and don't know about its internals, but wanted to suggest this limitation (at least until it's implemented) to be notes in the readme.

[GoWebProd]

Fix of this was offered in #236