-
Notifications
You must be signed in to change notification settings - Fork 317
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
Golang: Display Go external libraries based on importpath structure #2973
Conversation
Thank you very much for this PR and sorry that it took me a while to review! Unfortunately, I don't think that we can upstream the changes as-is. In particular, it worries me to let state leak out out of TreeStructureprovider is the right way to go since changes there will only be cosmetic for the user. We can get the current project state via Then, we only need to use the DFS that you've already drafted up to create the right structure. TestingIn terms of tests, I think, the ideal point would be a unit test which checks if the tree structure is properly generated (i.e., a test for different scenarios of How to move aheadLet me move ahead with drafting up a PR based on this and then you can tell me if it would work for you (let's flip the script). I'd make it so you are co-author of the change on GitHub when it gets submitted. I'd probably also want to have this change behind a feature flag, just to be sure that users who don't want this can fall back on something. |
That makes sense about not wanting to leak state and sounds like a good plan forward. Thank you @AlexeyGy ! |
Any update? |
Can someone please merge this thing - it's so annoying |
@jastice FYI |
@AlexeyGy maybe you could publish your draft PR so that somoebody could pick it up? |
Never wanted a PR so bad ❤️ @linzhp |
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 401216309
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 401216309
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 401216309
New PR is finally out: #3833. Under internal review. |
🎉 |
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 401216309
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 401216309
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 401216309
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. ## Design choices: * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. ## Discussion thread for this change Issue number: #1744 #2365 ## Description of this change Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 ## Tests Unit tests added. PiperOrigin-RevId: 467145600
@blico once the change is merged, can we close this PR? |
Done! |
…bazelbuild/intellij PR import #2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. Issue number: #1744 #2365 Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks. Closes #2973 Unit tests added. (cherry picked from commit 4d0f56b)
…bazelbuild/intellij PR import bazelbuild#2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. Issue number: bazelbuild#1744 bazelbuild#2365 Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within bazelbuild#2365 for an example of how the new structure looks. Closes bazelbuild#2973 Unit tests added. (cherry picked from commit 4d0f56b)
See bazelbuild#2365 and bazelbuild#2973 for context. (cherry picked from commit 0194efa)
See #2365 and #2973 for context. Co-authored-by: Brandon Lico <[email protected]>
…bazelbuild/intellij PR import bazelbuild#2973) This is a modified version of the original change by Brandon Lico with a few modifications: * read from the fileToImportPathMap directly when modifying the structure * add unit tests. * We don't inherit from BlazeExternalSyntheticLibrary since that contains irrelevant logic. Also we can't logically fulfill the "Only supports one instance per value of presentableText." condition that's outlined in the class javadoc since we could have nodes with identical presentableText properties in the tree in different positions. Issue number: bazelbuild#1744 bazelbuild#2365 Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within bazelbuild#2365 for an example of how the new structure looks. Closes bazelbuild#2973 Unit tests added. (cherry picked from commit 4d0f56b)
See bazelbuild#2365 and bazelbuild#2973 for context. (cherry picked from commit 0194efa)
Checklist
Discussion thread for this change
Issue number: #1744 #2365
Description of this change
Modifies the structure of the external "Go Libraries" project view to be based on importpath rather than a flat list of files. See my comment within #2365 for an example of how the new structure looks.
This is essentially achieved by extending Go's
additionalLibraryRootsProvider
to carry external dependency importpath mappings and then using that information from a new GotreeStructureProvider
to create the importpath based directory structure.Due to my unfamiliarity with this project and the lack of pre-existing tests I struggled to write tests for this feature. If anyone more familiar with the codebase could provide some guidance that would be very helpful.