-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/go: print file name when showing an import cycle #66078
Comments
As a minor nit, I think it would be slightly clearer like |
I don't think it's a nit, any suggestions to improve the formatting are appreciated! I don't have a good recommendation or a strong preference here. I mostly just care that the data is exposed to the user =D One suggestion: make it easy for terminal users to copy paste out the filename. On the end is easy for most terminal emulators for example. Other ways are possible too. |
@xin-tsla sent a CL implementing something similar to this. The big difference in their CL is that it used full absolute paths with line numbers. That would make jumping to the import in an editor easier, but I agree with @purpleidea that we shouldn't print the full absolute paths. I don't have a strong opinion on the line numbers, but they're not as useful if we don't have absolute paths. It would make finding the import easier, but it's usually not very hard to find an import in the top of a source file. |
Hi All, in the CL(https://go-review.googlesource.com/c/go/+/597035), we have the basename in the stack, the error message looks like following:
![]() In my IDE, it somehow supports to jump to file location even it is a base name. |
I don't think including the line numbers is helpful since 99% of the time all the imports are all at the top anyways, and if not they'd be easy to find. The downside however is that those paths are not directly copy+pasteable into a terminal, so this is less ergonomic. The IDE's can handle not having the line numbers. If we really want to do this properly, then we should use terminal hyperlinks, like so: https://purpleidea.com/blog/2018/06/29/hyperlinks-in-gnome-terminal/ |
Thanks for the info! @purpleidea |
@purpleidea , it is a good blog to read, thanks for writing and sharing the knowledge! Good to know the hyperlink and escape sequences chars on terminal.
As your point in the comment, it makes sense to have the file name without linenumber.
![]() Wondering are we all in alignment on the proposal? cc: @purpleidea @matloob @mknyszek @bcmills |
I think this looks reasonable but I think it's enough to list just one file per import |
@matloob thanks for the comment! |
So I don't think we need the "and more" either. The import cycle error is just showing one path that contains a cycle, but there could be more, so i think that it's implicitly clear that we're just showing one route. |
@matloob got it. Addressed the comment and submitted: |
Hi @matloob , @purpleidea , |
That sounds good to me. |
@matloob , great! Thanks for the info! 👍 |
I don't think we need a label. Let's proceed with the review |
@matloob https://go.dev/wiki/HandlingIssues suggests issues should have one of the Needs{Investigation,Decision,Fix} labels after they're triaged. Removing NeedsInvestigation without adding something else puts it back in the untriaged queue. NeedsFix seems like the best fit, but feel free to adjust. Thanks. |
Oh thanks- NeedsFix is correct. |
Thanks all for helping to finalize the proposal!! |
Change https://go.dev/cl/597035 mentions this issue: |
We've all hit the common:
It would great if it showed the actual file name of the imports, so that when there are multiple files in a package, it's easier to narrow down which one is the offender.
Eg:
Of course a more symmetrical approach might look like:
But whatever the formatting the code idea is that we make it easier for the user to know which file was part of the loop.
What about the situation of more than one file offending? Well this is a topological sort, so we already only guarantee that we print a single loop, even when there are more than one paths.
Of note, we don't want a full absolute path printed, we already know where things should be based on package name, we do care about the relative file path in that package.
Thanks!
The text was updated successfully, but these errors were encountered: