Use of dep in libraries (manifest)

[nathany]

Does it make sense to use dep in repositories that are primarily libraries for others to use?

If I run dep init, the manifest only lists the dependencies:

{
    "dependencies": {
        "golang.org/x/sys": {
            "branch": "master"
        }
    }
}

But what about information about the project itself?

If there is a central registry/index in the future (#175), can all the necessary metadata be extracted from godoc comments, git tags, LICENSE files, etc.?

If not, this could also impact whether the manifest is considered human-editable and what file format is most suitable (#119).

[sdboyer]

Yep, dep is intended for projects of all stripes - pure libraries, mixed libraries and apps, pure apps, to share or not to share. If you write Go, dep should be useful, period.

It is especially weighted in favor of code that's intended to be shared. We've focused there first because that's the harder problem, and the problem we have to address for not just awesome projects of our own, but a healthy ecosystem as a whole (which, of course, ends up making our own projects more awesome).

There's two general rules that have motivated what's in the manifest so far:

1. Do not put anything in there we do not need, immediately right now
2. Do not put anything in there that we can unambiguously extract from static analysis

wrt manifest format...yeah, It's a good point that, if we plan to have registries, we're unlikely to be able to get everything we need from static analysis.

[nathany]

Maybe it would be worth listing the metadata projects might declare so consider if everything can be retrieved via static analysis. If it can, that may be preferable.

• name (git repo name or godoc?)
• version (git tag)
• license (based on LICENSE file contents)
• summary (godoc package description)
• authors (git committers or AUTHORs file if this is needed?)
• homepage (nicety, may not be necessary)
• required go version (build tags)
• supported platforms

[sdboyer]

IIRC @mattfarina put together a google doc that tried to itemize just such a list of properties...can't put my hands on it right now, though.

[mattfarina]

Sorry I'm late to the game here. Are you talking about https://github.com/mattfarina/pkg?

Is dep open to a contribution that brings in some of these properties?

[JeanMertz]

Yep, dep is intended for projects of all stripes - pure libraries, mixed libraries and apps, pure apps, to share or not to share. If you write Go, dep should be useful, period.

I was looking for more details on using dep for libraries as well. Specifically, I can't find any details on if I should commit the lock file in my repository or not.

My toml file specifies some versions using the carrot (^) constraint, to make sure major version updates for dependencies aren't allowed. I did find this in the user stories doc:

US21 As a library author, I want some way of specifying compatible dependencies, which can be overridden by whomever imports me if necessary. [+EM] [+JF] [+SB] [0AG] 3

But in the end, I am not sure if I should bundle the lock file with my project, or leave it out to provide the most flexibility for other projects using my library.

[JeanMertz]

$ dep ensure -vendor-only
no Gopkg.lock exists from which to populate vendor/

I guess that answers my question :) Gopkg.lock should always be committed, no matter the type of project you're working on.

[sdboyer]

yep! currently, Gopkg.lock is ignored in libraries, though we may eventually be able to use its contents as a hint, in certain circumstances.

…

On September 23, 2017 6:43:27 AM EDT, Jean Mertz ***@***.***> wrote: ``` $ dep ensure -vendor-only no Gopkg.lock exists from which to populate vendor/ ``` I guess that answers my question :) Gopkg.lock should always be committed, no matter the type of project you're working on. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #208 (comment)

[JeanMertz]

Just out of curiosity, when is a project considered a library? The lack of a main.go file?

[sdboyer]

there isn't much formal discussion of it, which is kind of the point - dep is designed around the idea that usage should not need to vary. but, here's the way I think of it: given that a project contains N non-`internal/*` packages and M main packages (and that N > 0), if: * M == 0, it's a pure library * N =< M, it's a pure app * otherwise, it's a hybrid

…

On September 23, 2017 11:03:43 AM EDT, Jean Mertz ***@***.***> wrote: Just out of curiosity, when is a project considered a library? The lack of a `main.go` file? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #208 (comment)