Basic go module support.

[stephen-fox]

I did not see a pull request for this. I am not sure if it is desired at this stage in development. However, go modules make it possible to compile the code base's applications outside of the GOPATH.

[pmazzini]

Thanks for your contribution @stephen-fox.

The linter check for tip is failing but it doesn't look to be related to this diff.

I think it is related to golangci/golangci-lint#605.

[pmazzini]

lgtm

[insomniacslk]

currently we don't have any remotely stable version yet, so the plan is to add modules support later on. I think at this stage versioning would be more problematic than helpful, but since I don't have a load of experience with it I'm happy to hear counter arguments

[stephen-fox]

FWIW, the modules feature supports replacing dependencies with local copies. This can be used to emulate the current behavior of the GOPATH. For example (from the link above):

replace example.com/project/foo => ../foo

This may be suitable for rapid development. I am not sure what your (or the other maintainers') workflow looks like. I have used the replace feature on unreleased projects to help me formalize stable dependencies while simultaneously developing the remaining unstable dependencies. But that is just me working by myself, or with one other person. I can see modules being useful for standardizing dependencies for contributors so no one adds code based on untested dependency releases (e.g., a major API change). There is also a security angle to this, as the go.sum file tracks hashes for dependencies.

One way or another - this is a cool project. I look forward to following its development :)

[vtolstov]

Yes go.mod will helps a lot to speedup development and testing.
I'm always use replace hack other package test it and provide pr after that

[insomniacslk]

ok, let's go ahead with this. Not much personal time to work on coredhcp, so contributions are very welcome :)