Feature suggestion: Distinguishing between ex-repo, intra-repo, and internal packages about gofumpt

[mvdan]

I don't know how plausible it is for gofumpt to understand the distinction between "packages in the same repository" and "external packages"—the module specification makes it seem that it might be able to if it's able to resolve the repository.

That's #38, and certainly planned. It's a fairly well understood and followed rule as well. I just got stuck on some of the minor design details, like where to draw the boundary line.

As for making a fourth group for internal packages - I personally haven't seen this style in any project before, and since we don't want gofumpt to have any options where possible, I'm inclined against it. We could always allow the user to create such a fourth group themselves, and teach gofumpt to leave it alone, but in my opinion that's not useful - the groups are only easy to maintain if a tool does it for you, not if you have to do it by hand.

[mvdan]

I'm going to close this for now in favor of #38, per the above. Happy to reopen if there are good arguments for reconsideration.

[adamroyjones]

I'm sorry for being slow to reply; the wind left my sails.

---

I'm going to close this for now in favor of #38, per the above.

That's all entirely (and characteristically) reasonable. This is better considered as part of that. It covers the more important distinction between standard, ex-repo, and intra-repo packages.

I personally haven't seen [the four-group] style in any project before, and since we don't want gofumpt to have any options where possible, I'm inclined against it.

There's a context where this style makes sense: a large Go monorepo comprising many services. In my experience, the distinction between internal and intra-repo packages becomes a useful one. (It's important for obvious reasons that services not import each other's innards.)

But that's a narrow context and gofumpt is a broad tool. If you've not seen that style, then it's better that I not impose any further.