Add go.mod functionality

[iilonmasc]

I've updated this module to be go.mod compatible.

This avoids duplicate code while still enabling people to use both versions in their imports.

I'm not sure whether GitHub would add the tags to the PR so I added a small note to the last two commits.

Commit b60e4a5 should be tagged as v1.x.y

Commit 5335d2b should be tagged as v2.x.y

[sam-github]

I'm also interested in module support.

Why did you choose such a radical rearrangement of the source over the simpler setup from https://research.swtch.com/vgo-module that is basically what is already used, the“major subdirectory” convention?

PRs don't include tags. I'm confused by your tags v1.x.y and v2.x.y, neither are valid semver if you meant that literally. Did you mean that the authors here should choose numerical values for x and y in the above?

[iilonmasc]

Why did you choose such a radical rearrangement of the source ...

As I already said “to avoid duplicate code”. This is more of a personal opinion though. I prefer to have either a single master branch with corresponding tags or Version branches ( the “major branch” convention)

Did you mean that the authors here should choose numerical values for x and y in the above?

Yes, sorry I should have made that clear. As you clarified PRs don’t include tags, the authors would need to tag the respective comments as v1.0.0 and v2.0.0 or similar.

[sam-github]

@sambadevi Doesn't removing the v2/ sub-directory break every existing dependant of this module who is using it from GOPATH with import getopt "github.com/pborman/getopt/v2"?

[iilonmasc]

@sam-github That's correct. Since go modules are supposed to be the default way to go in future golang versions, I assume switching to go.mod would be the preferred way to go.

Taken from https://blog.golang.org/using-go-modules

Starting in Go 1.13, module mode will be the default for all development. [...] Go modules are the future of dependency management in Go. [...] We encourage you to start using modules in your local development and to add go.mod and go.sum files to your projects.

[sam-github]

I don't think breaking all existing users of a package unnecessarily is the way to transition to modules. The go authors take backwards compatibility and orderly transition pretty seriously, I doubt this is the kind of encouragement they suggest. I guess you'll see if @pborman feels differently.

[pborman]

My understanding was when a major backwards breaking change is added a new directory is needed and adding a v2 directory is the accepted form. I would like to drop version 1 (main directory) and only have version 2, but that would break existing code.

I would actually recommend using my options package (it imports v2) as I think it is my best attempt at making a fully functional, easy to use package that is fully posix compatible. I need to sit down at a computer (not a mobile device) to examine this further.

[jfesler]

any update on this? It's getting frustrating when people depend on my libs that use github.com/pborman/getopt/v2.

github.com/pborman/getopt/v2: ambiguous import: found package github.com/pborman/getopt/v2 in multiple modules:
	github.com/pborman/getopt v0.0.0-20190409184431-ee0cd42419d3 (/Users/xxx/go/pkg/mod/github.com/pborman/[email protected]/v2)
	github.com/pborman/getopt/v2 v2.1.0 

This is getting to be enough of a support headache to fork the repo, which I'm actually quite loathe to do (I hate unnecessary forks).

There is no longer a supported version of Go that can't use go.mod (and hasn't been for quite a while).

FWIW, I have a lot of published /v2 modules that work fine, without the subdirectory. I maintain two branches instead of two directories.

Go will look at the github tags, and for people still on v0, if any v1.x.x tags are found, will use the latest of those tags. And for people using /v2, it'll use the latest of the v2.x.x tags.

[pborman]

My issue with the proposed change is that it breaks existing programs.

I have to say I have personally never liked how go modules work as they make the type of development I do (I work on multiple packages that interact with each other) more challenging. Heck, you can't even call "go get some.module" if you are in a fresh source tree, you heed to say "GO111MODULE=auto go get some.module"!

That all said, I would welcome some advice on how to fix the existing go.mod files without breaking existing code.

Thanks