Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/cmd/goimports: ability to disable pkg renaming #23004

Open
pkieltyka opened this issue Dec 5, 2017 · 5 comments

Comments

@pkieltyka
Copy link

commented Dec 5, 2017

go version go1.9.2 darwin/amd64 and golang.org/x/tools/cmd/goimports @ 04447353bc504b9a5c02eb227b9ecd252e64ea20

For packages that manage versioning through import paths, such as "upper.io/db.v3" or "google.golang.org/api/youtube/v3" goimports will import these packages as:

import (
  db "upper.io/db.v3"
  youtube "google.golang.org/api/youtube/v3"
)

although it may be a useful hint to readers to see the explicit package name for the path, my preference is to use package renaming only when I'm actually renaming a package, and I tend to understand the packages Im using and their name as db or youtube.

I've determined findImport() in https://github.com/golang/tools/blob/master/imports/fix.go#L734 to be the function that provides a rename functionality, later set here: https://github.com/golang/tools/blob/master/imports/fix.go#L258-L260

Is there any interest to have the ability for the goimports cli to have a flag -norename that will turn off automatic package renames on import as described above? if so, I'm happy to work on a submission. I understand this is only an aesthetic suggestion and I've already forked the project for my own purposes, but I know others on my team felt similarly so I'm seeing if we can add this as a dedicated option.

thanks.

@gopherbot gopherbot added this to the Unreleased milestone Dec 5, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 5, 2017

Is there any interest to have the ability for the goimports cli to have a flag -norename that will turn off automatic package renames on import as described above?

No, I don't want any flags.

People run this from their editors more than they do by hand. There's no place to put flags.

Also, the whole point of things like gofmt or goimports is to have conventions that everybody uses, even if they don't all 100% agree on them. Adding flags for people's preferences seems antithetical to the spirit of such tools.

@pkieltyka

This comment has been minimized.

Copy link
Author

commented Dec 5, 2017

@bradfitz good point about going against the spirit of such tools and flags just add more knobs that pollute the experience. Totally agree.

My point is I don't like auto pkg renaming enough to post this issue and fork my own version to disable it :)

perhaps then we could add to imports.Options{} to disable renaming, and export gofmtMain() in goimports.go and accept the options as an argument. Then I could just easily wrap/roll my own with set options.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 5, 2017

Or you could just fork goimports if you don't want to use goimports. :)

Why complicate the code base for everybody else, just for one user who wants to be different?

If it's just for one user, that's too much complication and maintenance cost.
If it's for 50% of users, then we're encouraging a split in the community conventions, and we shouldn't do it.
If it's 100% of users, then we wouldn't add options and would just change the default.

So whether it's 1 person, 100% of people, or anywhere in between, we shouldn't add options.

@DeedleFake

This comment has been minimized.

Copy link

commented Dec 5, 2017

People run this from their editors more than they do by hand. There's no place to put flags.

That's not necessarily true. vim-go provides a g:go_fmt_options variable that you can set to pass flags to whatever command it's running instead of gofmt.

Adding flags for people's preferences seems antithetical to the spirit of such tools.

Then why does goimports exist? Why not just have the import functionality built-in to the standard gofmt? I assumed that it's because modifying imports isn't technically a 'formatting' thing, which I would think then implies that the flag that's being requested falls quite cleanly in the same category.

Edit: The already existing -s flag that gofmt has seems pretty similar to this, too. It makes changes that seem to be more of a matter of opinion, rather than being standardized formatting.

Edit 2: Actually, reading through go doc gofmt, it seems more likely that it's because the changes that it makes aren't backwards compatible. Never mind.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 5, 2017

Then why does goimports exist?

gofmt can't make mistakes and can't be slow.

goimports can.

I wrote it for myself on a long flight and started with it out-of-tree. It was at https://github.com/bradfitz/goimports and then we moved it to x/tools at some point. By having a different binary name, you opt-in to the potential mistakes and slowness.

Perhaps it could be part of gofmt, but then it'd need more flags. It seems fine being a separate binary.

But that doesn't mean we want to start adding lots of options, just like we don't want gofmt to have lots of options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.