feature: support multiple local import groups about gci

[heedson]

That is a little murkier. I'm not a fan of what I'm about to say but that's not the "Go way". As you said PEP 8 is recommended for Python, Go usually has stdlib followed by a number of ways to represent the next imports.

Common ways are:

• all as 1 clump
• 3rd party followed by internal (or org)
• what the initial question of this issue raised (splitting org into org and internal)

I'm sorry that's a little hand-wavey but it's the only reason I'd say it's not common - it's non-standard (your new example).

As for standard, I think the standard is approach 2 that I listed. You have 3 blocks - stdlib, 3rd party and then your own org stuff. A lot of people I've encountered also don't "care" enough about it so also go with approach 1 often enough. I think this issue is also interesting and it's something I'd consider myself as I like seeing the differences between internal/org/external/standard.

Hope any of this helps or is interesting.

[jackwhelpton]

Similar request here, although we combine the last two in a single group. As a specific example, gci is rewriting:

import (
	stdcsv "encoding/csv"
	"strings"
	"testing"

	"github.com/google/go-cmp/cmp"

	"github.our-company.com/attr-dict-import/source"
	"github.our-company.com/io/csv"
)

to:

import (
	stdcsv "encoding/csv"
	"strings"
	"testing"

	"github.com/google/go-cmp/cmp"
	"github.our-company.com/attr-dict-import/source"
	"github.our-company.com/io/csv"
)

Perhaps the simplest change might be to group non-stdlib imports by hostname?

[heedson]

@jackwhelpton Have you tried using the -local flag? It seems to sort what you are looking for.

I believe (not tried with only hostname - have done so with org name) gci -w -local github.our-company.com will result in:

import (
	stdcsv "encoding/csv"
	"strings"
	"testing"

	"github.com/google/go-cmp/cmp"

	"github.our-company.com/attr-dict-import/source"
	"github.our-company.com/io/csv"
)

Is this what you're looking for?

[jackwhelpton]

Ah, I'd missed the config options as I'd been running through golanci-lint: setting those up now. It's close, but I realize my example was actually flawed. What if I want to have our-company imports before third-party imports? This is similar to what PEP 8 recommends for Python. For the above example it would lead to:

import (
	stdcsv "encoding/csv"
	"strings"
	"testing"

	"github.our-company.com/attr-dict-import/source"
	"github.our-company.com/io/csv"

	"github.com/google/go-cmp/cmp"
)

That said, most tools I'm finding for import grouping seem to favor the way gci is currently operating, so I'm wondering if we should update our internal standards... is there a convention on this?

[jackwhelpton]

No need to apologize, that's helpful. We've been trying to adhere to Go conventions as closely as possible, I think I just hadn't realized there was a common way of organizing these groupings. It's sometimes hard to find examples (because most public code doesn't have the "our organization" concept), but given the prevalence of the tooling against me I'm willing to shift.

Actually, one last piece of bikeshedding before I stop derailing this thread: does prevailing wisdom and/or gci have an opinion about golang.org/x packages? We've tended to have them in their own group directly beneath the stdlib ones, as they're kind of "std-ish"...

[heedson]

From what I can tell and in my experience, they get lumped with the other 3rd party stuff. I was looking through the source of this repo earlier and found it a little humorous that the way this detects what is "stdlib" is if the string of the import doesn't have a . (dot) in it! So if I'm being accurate, I guess the first clump after stdlib is just "external" imports! 😄

[jackwhelpton]

Fair enough: I can live with that in order to get the benefit of not having to bother about this again (gofmt rules). We make light use of the language package for BCP 47 stuff and that's about it. Right, apologies to the OP, back to the topic in hand... :)

[daixiang0]

Now support by multiple prefix:

sections:
  - Standard
  - Prefix(github.com/local)
  - Prefix(github.com/daixiang0)