[feature idea] Configurable GOPATH per project

[dvirsky]

Say I'm working on 2 projects, each with its own set of dependencies and its own GOPATH.

Why not let me define GOPATH per project, and force the project to be inside it? It will still stupport multiple projects in a single GOPATH, but if I want better isolation, I can always make a project work with a specific GOPATH.

It can be done today by setting env vars, but wouldn't it be more idiomatic to make it part of the environment?

Just a thought....

[dlsniper]

There are two causes for this:

• we decided to support the most common use cases / simplest way to integrate with existing environments
• we all have full time jobs and day to day 'distractions' so time is a critical factor.

Contributors are welcomed :)

[dvirsky]

I don't mind trying to add this, but do tell me if this is something you'd like to see.

[dlsniper]

Well, it's something you'd like to see so why not? I guess there are others that would want to see it as well :) There's already a ticket for it: https://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/458

So, if you want to work on it, sure. Just as an idea on how I would do it:

• on project creation I would ask the user to verify if he's happy with the current GOPATH from system
• if not, he could change it accordingly
• later on, the user should be able to change that path as well

The tricky part is to support all sorts of ways the GOPATH can be and always add the first directory to the SDK then refresh the SDK correctly and purge the old SDK cache. It would also mean to handle what happens when there are two projects with two different paths in SDK and how should that work internally for IDEA.

Feel free to work on it and ask me or @mtoader for input / help if you get stuck.

Thanks for helping out.

[dlsniper]

Obviously, due to speed, I've got something wrong. GOPATH paths should be added as libraries to the project not as part of the SDK. The current way is a hack to make this work but the correct way should be implemented due to advantages it has (keeping the same SDK, libraries can be better refreshed and so on...)

Thanks to @mtoader for pointing it out.

[mtoader]

That's my job here ;)

[dvirsky]

I see that the project configuration already has a place holder for goPath, and adding editing of it to the config dialog was the easy part. now can you guys please point me to the bits of the code where I should take this into consideration? all the sdk helpers are a bit confusing :)

[mtoader]

Yea.. they are and we are sorry about this (especially me). Basically since you want this you would have to ask @dlsniper to help you (he has more knowledge about this than me atm) :).

[akaspin]

Bump

[dlsniper]

Sorry for delay.

I've searched devnet and here's what I could find on the topic:

• http://devnet.jetbrains.com/message/3543282#3543282
• http://devnet.jetbrains.com/message/5184987#5184987

The workflow as I see it, @mtoader please correct me if I'm wrong, would be the one I've mentioned. There is however the problem of actually adding the paths for the libraries fetched with go get into some folders which could be tricky and it's where the plugin should be really smart about it and either detect them properly or be very configurable.

Also, the plugin should be able to properly detect changes / editing to existing libraries at load time of a project, you can grep for git.io to see where that happens.

I'm not sure which kind of help are you looking for so please be more explicit about it.

Hope it helps.

Regards

---

Florin Patan / @dlsniper https://twitter.com/dlsniper https://github.com/dlsniper http://www.linkedin.com/in/florinpatan

On Thu, Jan 16, 2014 at 6:13 AM, Alexander Dorofeev < notifications@github.com> wrote:

Bump

— Reply to this email directly or view it on GitHubhttps://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/538#issuecomment-32442983 .

[dvirsky]

I'm actually thinking this might not be the best way to go. The whole libraries area is very confusing for non-Java projects (and for Java projects too, a bit IMHO but that's besides the case). and GOPATH is not a library in the idiomatic Go sense. In fact, as a user I would have liked the whole confusing SDK and library dialogs to become just one simple dialog:

1. select GOROOT (select sdk)
2. select GOPATH
3. Thank you very much :)

But anyway, that's another issue. my question was about how the whole path resolving works, which classes handle it, etc.

[dlsniper]

Short answer: I have no clue. @mtoader is the better person to answer this one. But keep in mind that the the GO way and the IntelliJ way might not be at all in sync due to the different nature of GO from the rest of the programming languages :)

[dvirsky]

Just for the sake of this discussion, the way ideally I'd want a Go IDE to work is:

1. The only paths recognized are GOPATH(s) and GOROOT
2. Projects reside within GOPATH, and you specify the project root for the go tools.
3. the above means no relative imports support.
4. The user is encouraged to create a GOPATH per project or per workspace.
5. Build output goes automatically to $GOPATH/bin
6. go-get installs to GOPATH and can run automatically (like PyCharm runs pip if you have a requirements.txt file)
7. This will allow easy integration of godoc, go race, etc etc.

[dlsniper]

Please see below:

1. we already have this, albeit is not customizable from IDEA directly (you can do some ENV tweaks to get it how you want)
2. we already support this
3. iirc we don't support relative imports (test case would be nice)
4. false. that's your particular use case. There's nothing that says how the user should use either GOPATH nor organize his projects. I have a different layout that you, one of my colleagues has a different layout that me and so on. We shouldn't encourage anything imho.
5. you can specify where the build goes already
6. while go get doesn't run automatically, we already support it (it's an intention when you are over an import section)
7. I'm not sure I understand this. We support go build / run (--race), go fmt, go get, (go app engine). What would be the value to support godoc or, as seen in another thread, goimports (which is useless in our particular situation)? Can you please detail a bit more?

[dvirsky]

re 3 - the syntax completer recognizes only relative imports if your project is inside GOPATH, but the compiler doesn't know what to do with them. So you're either stuck with no completion or no compilation :)

say I have this in a project that sits in $GOPATH/src/example.org/myproj and has a package called 'foo'

package main //we are at the root of the project
import ( 
     "example.org/myproj/foo" // <-- works for the compiler but no completion
     "foo" // <- allows highlighting but the compiler fails, as it should
)

re 6 - it would be a nice touch to add to Tools -> Go Tools -> "Go-Get Everything" or something like that

re 7 - running GoDoc (maybe as a slave webserver) will help me read the documentation of go-get'ed packages, and work on the documentation of my own project. It's a bit tricky to run go doc correctly, so it might help people.

[dlsniper]

3 I'll need to check it on how it behaves, maybe @mtoader is interested by this as well :D 6 I think it could be fairly easy to do but do you find the usage of the go get and go get -u intentions too complicated right now? I usually copy-paste some code of the net, go to the import block, ALT + ENTER, run go get and that's pretty easy (again, for me). If you want, you could implement it by looking on how the other actions are done, for example, how go sdk debug stuff runs and get the remaining code that you need from the gogetintention 7 as above, initially can be done fairly simple but I would love to see an additional panel in IDEA with godoc output in it (not sure if / how can it render html content. That would be a fantastic feature. Maybe get some help from JetBrains DevNet: http://devnet.jetbrains.com/community/idea/open_api_and_plugin_development on it?

I would love to work on these myself but time constrains in the couple of days + I really want o finish #535 (which you have to admit it would be very cool to have ;) )

[dlsniper]

I've asked on DevNet about the last point. Lets see what they have to say about it :) http://devnet.jetbrains.com/thread/452129

[dlsniper]

So... anyone up for doing the godoc + dispaly of docs in a panel / tool window? :D

[dvirsky]

do you think the "crappy html" they suggest would be enough for godoc?

[dlsniper]

Closing this in favor of #867