<p>I have some local packages defined within my application, for example, I have a crud model located at model/crud/crud.go</p>
<p>Within my application I am calling upon them using <code>import("model/crud")</code>, for all of my local dependencies.</p>
<p>This resolves perfectly fine within the context of my application on my local machine, however when I try to push to openshift I get the following error:</p>
<p><code>imports model/crud: unrecognized import path "model/crud"</code></p>
<p>It looks like when openshift runs the build tool, it is attempting to run <code>go get</code> on these imports in order to include them in the build path when compiling. </p>
<p>Is there a better way to resolve vendor specific dependencies without having to create a separate repo for them? I don't want to have to manage two separate repositories if I don't have to.</p>
<p>I posted this on Stackoverflow if you'd prefer to get reputation for your answer there. Any help is greatly appreciated.</p>
<p><a href="http://stackoverflow.com/q/31094283/1400450">Post on Stackoverflow</a></p>
<hr/>**评论：**<br/><br/>anoland: <pre><p>I'm having the same problem on openshift. Openshift does the import to a non standard subdirectory that 'go get' doesn't know how to find. The closest I have come is to put a <em>.gopath</em> file in the root of your openshift repo for a place to put the repo code. I haven't resolved the import path from that location yet.</p></pre>uabassguy: <pre><p>Hmm, interesting to see that I'm not the only one having this issue. It'd seem more effective if they used something like docker rather than than go cart. </p></pre>anoland: <pre><p>The next version is based on docker. I don't know how soon that will be released tho.</p></pre>uabassguy: <pre><p>Cool. Yea I saw that go cart was copying to the gopath which seemed to immediately break because the repo itself was in an entirely different location. That and there is limited write access within the home folder to repair those with symlinks. Seemed not very well thought out, or was designed with the purpose of working with external repositories exclusively. Didn't make sense to me. </p></pre>joefitzgerald: <pre><p>While this may be a completely unproductive response (i.e. if you're required to use or are sold on OpenShift, feel free to ignore), have you tried other PaaSes, like Cloud Foundry (disclosure: I work for Pivotal), or Heroku? In both scenarios, you can actually just use the null buildpack <a href="https://github.com/ryandotsmith/null-buildpack" rel="nofollow">1</a> which executes a binary that you produce in your CI pipeline. There is also a full lifecycle buildpack for CF <a href="https://github.com/cloudfoundry/go-buildpack" rel="nofollow">2</a> and Heroku <a href="https://github.com/heroku/heroku-buildpack-go" rel="nofollow">3</a>.</p></pre>khaki0: <pre><p>About the null buildpack, doesn't the git repo become too big quickly? I mean committing binary files - which in case of Go can be several MB or more - can cause the git repo to bloat pretty quickly. </p></pre>uabassguy: <pre><p>Just curious as to why binaries are being handled in this manner? Builds are generally supposed to be triggered by some sort of CI application like Jenkins instead of being deployed through VCS directly. </p></pre>uabassguy: <pre><p>I'm not married to the idea of using openshift, just saw that it was free for small apps and wanted to test response times of a web socket api in an actual server-client scenario. The main reason was the 'free for small scale' part since I'm still experimenting with go. </p></pre>klaaax: <pre><p>Which cartridge are you using? it seems the default one isn't even maintained (last commit in january). That's the issue with openshift compared to other paas like Heroku, their "buildpacks" are very poor in quality. you need to try another Go cartridge. But frankly I wouldn't bother for now. Nothing really works in openshift if you don't invest time to write your own shellscripts. I remember being unable to deploy the latest version of express.js (v3) because it conflicted with a nodejs library pre-installed on the default nodejs cartridge how fucked up is this ? </p>
<p>And since openshift 3 is moving to containers , they'll scrap their legacy architecture sooner or later,I don't want to be using that in production when everything breaks.</p></pre>khaki0: <pre><p>Where do you usually deploy your Go apps? I'm developing a Go+Postgres+Redis app and so far I think AWS and Heroku are the only viable options. </p>
<p>I like Heroku but it is just too expensive. For example the smallest database with a backup node costs at least $200/mo. </p></pre>uabassguy: <pre><p>I develop locally since I'm just recently jumping into go. I've been considering Go+Cassandra+Redis though. I'd be better off building my own test machine than paying 200 a month, that is a bit much, especially since this is an experimental personal project. </p></pre>uabassguy: <pre><p>Looks like they're using Go-cart and I was wondering why they weren't using docker but I figured 'eh, it's free for a small app, so why not?'. 3 hours later and I'm wondering why I bothered when I could have spent that time writing the code to simulate a server client scenario myself and saved the hassle. </p></pre>
