[ ← blog / golang ](/) Feb 25, 2018  ·  \#golang  ·  4 min read # GoLand IDE and local vendor directories At Florida DrupalCamp, I got to talk to the DRUD team. They were demoing their DDEV tool, which is an open source local development stack. For a while I have been using my own platform-docker tool, which is a PHP based tooling command I used for scaffolding Docker, running Behat, and more. Instead of maintaining my already unmaintained tool, I decided to give DDEV a try and contribute back some things which I considered experience fixes. At Florida DrupalCamp, I got to talk to the [DRUD](https://www.drud.com/) team. They were demoing their [DDEV](https://tech.drud.com/ddev) tool, which is an open source local development stack. For a while I have been using my own [platform-docker](https://github.com/mglaman/platform-docker) tool, which is a PHP based tooling command I used for scaffolding Docker, running Behat, and more. Instead of maintaining my already unmaintained tool, I decided to give DDEV a try and contribute back some things which I considered experience fixes. DDEV is written in [Golang](https://golang.org/). You can read more about its features and how to use it, I recommend hitting [the documentation pages](https://ddev.readthedocs.io/en/latest/). I have messed with Golang a little. It is pretty fun and I have been wanting a reason to fiddle around with it. There is just one major GOWTF: working with third-party libraries and the [GOPATH](https://github.com/golang/go/wiki/GOPATH). The GOPATH is where dependencies are downloaded and accessible. The default GOPATH is your in your home directory. As a Goland novice, I feel dependency management and locations are pretty confusing. The language feels great, but then there is this hindrance. I decided to get [GoLand by JetBrains](https://www.jetbrains.com/go/) installed and get a whirl at hacking on DDEV. A reason to use an IDE, over something like Visual Code Studio, is for all the fancy type hints and shortcuts to declarations. New to Golang I decided to use the typical "import from Git" screen which put my project in *~/GolandProjects.* But when I set up the project in GoLand I hit this. ![](/sites/default/files/styles/large/public/goland-dependency-unresolved.png?itok=y9e_QUb_) So then I was like "oh, okay. I just need to fix my GOPATH!" I tried everything, and I couldn't get it to work. I tried setting my Project's GOPATH to everything I could think of, and nothing would work. I found a [reported bug for the Goland IDEA plugin where vendor directory contents only worked if there was a **src**](https://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/2351) subdirectory. So I ran a script mentioned in the issues which makes a symlink of the vendor **contents** to **vendor/src**. I then configured GoLand to use the project's **vendor** directory as a local GOPATH. ![](/sites/default/files/styles/large/public/ggoland-gopath-wtf.png?itok=0kW_gsZ1) This was all fine until it needed to import packages provided by the repository itself. At this point, I was in a very "face meet desk, repeat" mood. I hopped on Drupal Slack and luckily [Randy Fay](https://twitter.com/randyfay) was online to help me troubleshoot. The packages *ddevapp*, *output*, and *util* are provided by the project itself. But, with Golang, the proper way to reference them is through the fully qualified dependency directory, or at least that is how I understand it. It seems like the GoLand IDE is not set up to handle this. It is above my head so I just followed what Randy suggested: Make life simple and install the DDEV source into my global GOPATH and hack on it from there. Works. For. Me. So I ran the following command ```bash # Create directories mkdir -p ~/go/src/github.com/drud/ # Move into the drud directory cd ~/go/src/github.com/drud/ # Clone my fork git clone git@github.com:mglaman/ddev.git ``` I then opened the directory in GoLand. ![](/sites/default/files/styles/large/public/Welcome_to_GoLand.png?itok=ryU48eNT) And everything worked! That is because the project was now within my GOPATH which allowed it to reference its own packages and vendor packages within the project. ![](/sites/default/files/styles/large/public/ddev____go_src_github_com_drud_ddev__-_____cmd_ddev_cmd_config_go__ddev_.png?itok=IZj100Se) So, now I know: when working on a Golang project to just stick to the GOPATH and keep it simple. ![](/themes/custom/mglaman/images/headshot.webp)Thanks for reading I write about Drupal, PHP, and the quiet infrastructure behind large sites — caching, config, and testing. New posts land every week or two. [Subscribe via RSS →](/rss.xml) [About me →](/about-me) [← Older Joining the POSSE ](/blog/joining-posse) [Newer → Flush and run, using Kernel::TERMINATE to improve page speed performance ](/blog/flush-and-run-using-kernelterminate-improve-page-speed-performance)