remove go module settings

[shirou]

from #663 (and also related to #681), I think go mod is not match for us currently. so I just remove go module settings in this PR.

When a situation changed, this change will be reverted.

[Lomanic]

If it fixes all our issues with go modules, then let's delete go.mod indeed.

[jefferai]

@shirou all you needed to do was update the module path in the go.mod file. Now the library doesn't have any native handling with go modules users. Can you please revert this and just fix the go.mod file?

[shirou]

I have tried update module path in go.mod, but no luck. from this blog v2 libraries with separate branches is not so supported. But I don't want to separate directories for this version. So, I decide not support go mod at least go module becomes default for all supported version (that means 1.15) because go mod breaks backward compatibility to non-go module users.

[jefferai]

@shirou I think you are misunderstanding that blog. You can absolutely use different branches. You can even use the same branch and simply change the module version in go.mod.

Go modules relies on tagging only. If you want to use multiple branches, that's totally supported. Simply ensure that when you cut tags that you are cutting them against the correct branch.

So for instance you could have a v1 branch with
module github.com/shirou/gopsutil
and any v1 tags you cut (v1.2.3) you cut against commits on the v1 branch.

Then you can update master to have
module github.com/shirou/gopsutil/v2
and cut v2 tags (v2.0.4) against master.

When you want a v3 you can make v2 into a new branch -- or not, because all that actually matters is that the go.mod file in the commit that your tag points to has the correct version matching the tag version.