I'm really dont care about all this license related bla-bla-bla I'm software developer, not a lawyer. Why gonuts.io push me to add LICENSE file to the repo ?

How to reproduce:

1. Open just generated nut.json
2. Enter your tocken
3. Make some mistake - like write version number in field "V": "0.1.0",
4. Run nut generate

What I got: Warning: Can't load config from /Users/varyous/.nut.json: json: cannot unmarshal string into Go value of type bool

And all info from nut.json is lost. Its just replaced with blank nut.json file.

I expect: Error message what nut.json file format is invalid and link to nut file specification http://www.gonuts.io/-/doc/spec

How can I install to $GOPATH/bin? I don't want to install to $GOROOT. Maybe update the docs with information on how to install $GOPATH/bin.

I think for this tool to succeed, it's got to be as newbie friendly as possible. Thanks.

1. .nut.json should not be created if it's not present. Use-case: invocation of nut get on server. no changes required
2. .nut.json is updated by any invocation of nut command. no changes required
3. If .nut.json is empty, it should be generated silently, without "unexpected end of JSON input" warning. Use-case: first invocation. done
4. If .nut.json is not empty and incorrect, do not update it and exit with error message. done

I just wanted to say at a cursory glance, this looks great! I just started Go yesterday as a veteran Node.js dev, I was bummed by Go's lack of versioning. I was thinking about starting my own system, as seen here: https://github.com/jprichardson/go-commander with package.toml as the package metatadata file.

One thing that isn't clear. Where are nuts actually hosted? Does the site just do a redirect? How do you publish nuts?

Good start so far!

After much thinking I decided that flat namespace (gonuts.io/nut) is a bad idea. Let's add vendors.

Example: gonuts.io/gorilla/context gonuts.io/gorilla/mux ...

At first iteration, there will be one vendor per user. Projects/organizations may follow.

My first few tries with nut were total failure. I typed "nut publish" with no nut.json file and got no feedback at all.

Then I tried nut check and discovered that I should have a nut.json file. But the help didn't tell me what to put in it, and I still haven't found the docs (if they exist at all). I'd have expected "nut check" to say something like "use nut generate to start, and then type nut help json to see the format expected for the nut.json file"

I just discovered nut generate, which is nifty. It should say, "Now edit nut.json to customize it." so I'd know

When I made the version number "1.0", I got:

Bad format for version "1.0": parsed as [][]string(nil) (and a panic)

No indication of what I was supposed to do to fix the problem.

Also: I question the need to enforce a version number format. Why not a simple string? What if I like versions of the form 20130101?

I'd prefer for the JSON to look like this:

{ "Version": "1.0.0", "Authors": [ { "Full Name": "Jeff R. Allen", "Email": "[email protected]" } ], "Extra Files": [ "LICENSE" ] }

i.e. "Full Name" instead of FullName.

• nut get test_nut should also get and install all dependencies, recursive
• nut get should get and install all dependencies for package in current directory

1. I run
   nut generate

and got error message:

Now you should edit nut.json to fix following errors: Package summary in code should be in form "Package php_session_decoder ... ."

Its completely wrong, because in turn this message is not related to nut.json file at all. Instead this message should clearly say what you should add doc.go file to your package.

The second question - why do you push everyone to write package doc exactly in this form: "Package php_session_decoder ... ." I dont understand this. I think its my right to document my package as I want.

And its not clear at all what I must have dot at the end of the sentence. I understand what accordingly to english grammar rules I should do it, but run config generation tool - not english spell checker and I expect what it will generate nuts.json and nothing more.

Use cases:

1. ..* – any version
2. X.. – major version X
3. X.Y.* – major X, minor Y, any patch
4. X.>=Y.* – major X, minor at least Y, any patch (X.>=0.* == X..)
5. X.Y.Z

Case 5 is typical for application, 4 – for nut.