Cli: Support users who are using GOPATH mode

[lynncyrin]

Desired Outcome

I would like to use the methodology described here in this blog post => https://blog.golang.org/v2-go-modules to support users who aren't using go modules.

Specifically, that would mean moving to a directory setup like so:

github.com/urfave/cli @ master branch
/go.mod    → module github.com/urfave/cli
/v2/go.mod → module github.com/urfave/cli/v2

Risks

This proposed change will make the git repo most "noisy", in that there will be more total files in the repo. It will be a bit more confusing to direct new contributors to the right place to add code. I think both those issues are easily solved with strong documentation, though!

Motivation

The motivation here is the many many cases where we broke someone who wasn't using go modules, or were the reason why someone had to start using go modules. Examples:

• https://github.com/urfave/cli/issues/925#issuecomment-552683840
• https://github.com/urfave/cli/issues/925#issuecomment-553173182
• https://github.com/urfave/cli/issues/925#issuecomment-559121697
• https://github.com/urfave/cli/issues/926#issuecomment-552679445
• https://github.com/urfave/cli/issues/947#issue-528380907
• https://github.com/anubhavmishra/envoy-consul-sds/pull/4
• https://github.com/ethereum/go-ethereum/issues/20164

Non-goals

Even with this proposal, I would still consider v1 go be "locked" at 1.22.X. Which is to say, I am by no means suggesting that we start merging feature PRs into v1! v1 would remain in its "critical bug fixes only" state, it would simply live in the master branch.

Our Paths Forward

This section describes how our paths forward from here would effect each of the following types of users:

1. users using GOPATH mode, who have already updated
2. users using GOPATH mode, who have not updated yet
3. users using vendoring
4. users using go modules

If we don't make this change

1. users using GOPATH mode, who have already updated

These users will be broken again when we update the package to v3 https://github.com/urfave/cli/issues/833. This will also be broken again if we update to v4, or v5, etc...

1. users using GOPATH mode, who have not updated yet

All of these users are currently broken, and will remain broken unless they take some action. The most common actions people take are:

1. swap to using go modules, or
2. update to v2

1. users using vendoring

These users are currently ok, and will remain ok

1. users using go modules

These users are currently ok, and will remain ok

If we make this change

1. users using GOPATH mode, who have already updated

These users will be broken once, because they will update to downgrade from v2 => v1

1. users using GOPATH mode, who have not updated yet

These users will be fixed

1. users using vendoring

These users are currently ok, and will remain ok

1. users using go modules

These users are currently ok, and will remain ok

A comparison of the options

As you can read above, users in group (3) and (4) will be fine regardless of what we do.

So this decision is really about users in groups (1) and (2), we will be affected in the following way:

• if we dont make this change
  
  
  
  • #ff0000 group 1 users will be broken at _least once_ in the future
  
  
  • #ff0000 group 2 users will be broken _forever_
  
  
• if we do make this change
  
  
  
  • #ff0000 group 1 users will be broken _only once_
  
  
  • #00ff00 group 2 users will be fixed
  
  

In Conclusion

This problem space is complex, but the cost of _not making this change_ is much higher than the cost of making it.

[lynncyrin]

~@urfave/cli please review this issue and let me know if you're 👍 or 👎 ! I think it could potentially be a great help for our users.~

[lynncyrin]

~I just realized ... we can't do this, because v2 is already in master~

~So we can't change master back to v1 now, because that would be another breaking change. RIP me, software is hard.~

~I'm gonna close this~

[lynncyrin]

Re-opening this because I think it's viable to implement still. More details incoming!

[lynncyrin]

@urfave/cli I've reviewed this problem more thoroughly, and it's currently my recommendation that we make this change. Please review the 1st post in this issue and 👍 or 👎 it! Please also ask me any clarifying questions.

[lynncyrin]

Additionally, if (and only if) we accept this proposal, I will do the following:

• write a v1 => v2 migration guide
• write a v2 => v1 migration guide for GOPATH users who need to downgrade
• cc the maintainers of any known GOPATH projects before I merge this change

[lynncyrin]

@gravis can you add a comment in support here? I would like for it to be known to the @urfave/cli maintainers that people are interested in this, and I'm proposing that we do exactly what you mention here https://github.com/db-journey/journey/issues/16#issuecomment-559479698

[lynncyrin]

@purpleidea FYI this proposal would break your project again since you aren't using modules or vendoring, specifically we would have to revert this PR => https://github.com/purpleidea/mgmt/pull/571. Please let me know if there's any way we can make it so that this proposal doesn't break your repo, thank you!

As I explain in the OP, if we change nothing about your project - you will be broken once and only once, and it will simply mean that this PR https://github.com/purpleidea/mgmt/pull/571 has to be reverted. I can very happily make that change for you, if we go through with this plan.

[gravis]

@lynncyrin Sure.
Actually, I'm giving this advice while not following it myself, since journey and migrate have switched to v2 directly in their respective master branch without any /v2.
But this repo (urfave/cli) is much more used in dependent projects, and they will all have issues if theyy haven't switched to go modules yet.

[lynncyrin]

@AudriusButkevicius / @rliebz / @asahasrabuddhe anytime this week, can you read through this issue any let me know what you think? It's fairly time sensitive, so I'll probably close it if it's not looking like it's going to get 2 👍's by December 9th.

That said, please do ask me any clarifying questions 🙏

[AudriusButkevicius]

V2 is in master and you suggest to undo that?

This will break everyone that fixed up their code, yet continued without module support. These people are probably the most pissed off ones now, so pissing them off once more is less than great.

I'd rather new users had to fiddle with something.

Perhaps we leave this as is, and do it differently in v3. Having master shapeshift twice in a short timeframe is somewhat against my appetite.

[rliebz]

I agree with @AudriusButkevicius here—we'd probably be having a different conversation if we hadn't already cut the v2 release branch.

That said, from here, I don't think restructuring the repo is worth it to support users who use GOPATH mode without _any_ sort of dependency management. We have major version tags to indicate what to pin to if users aren't interesting in keeping up with breaking changes, so as long as users are using something like dep, glide, govendor, etc., they'd have effectively the same experience whether or not we do that restructuring.

[lynncyrin]

🙏 thanks for your comments!

This is at...

• 1 👍
• 2 👎

...so I'm going to close it ♻️

I think this will be a helpful issue to read for future people who are trying to figure out this same problem 📖👩‍🎓 so I appreciate everyone's input here tons ✨