<p>I know there is godep, but I am curious why go doesn't natively support versions via git url stub. Something along these lines</p>
<pre><code>import (
"os"
"github.com/uname/myrepo1"
"github.com/uname/myrepo2@dev"
"github.com/uname/myrepo2@c8ufj1"
)
</code></pre>
<p>That seems to fit go idioms fairly well. Is there a place that the language accepts feature requests? I wouldn't mind implementing this given a good direction to go in.</p>
<hr/>**评论：**<br/><br/>tv64738: <pre><p>This horse has been beaten to death on the mailing list.</p>
<p>What would happen if I import <code>database/sql@1</code> and you import <code>database/sql@2</code>?</p></pre>flydonkey: <pre><p>Throw a compiler error?</p></pre>agentargo: <pre><p>That seems totally reasonable to me</p></pre>danredux: <pre><p>I feel like I'm missing something, but why would it be an issue if people imported, hell, BOTH of those in the same package?</p>
<p>Sure, you'd have to rename one on import.. but that's all.</p></pre>calebdoxsey: <pre><p>Libraries often have state or initialization with side effects. For example if you imported two MySQL libraries the latter would probably overwrite the former.</p>
<p>You also wouldn't be able to transfer data between the two different versions because the types would be different. For example suppose you were using a redis library and passed around a redis connection everywhere in your own code. If you had two versions of redis included which redis connection would you define for you functions? (And how would you convert one type of redis connection to another?)</p></pre>danredux: <pre><p>I can't think of a situation where importing two versions of the same package would cause problems with overwriting initalization/state, excepting I suppose if some third package has some option that is changed between sql versions, and the value that sql@2 sets is incompatible with the value that sql@1 sets.</p>
<p>However the solution to this is quite simply- reset the "import" cache when importing a new version. IE, sql@1 and sql@1 get two entirely separate compilations of each package they import.</p>
<p>However, there's almost no state in packages at the top-level and this might not even be a problem. The packages could simply be aware that, to support versioning, they may not rely on third-party package state.</p>
<p>Edit: In fact, this is already an issue! Two parts of your program (or two packages) can both import and configure a third-party package's state. Nothing changes from versioning this way.</p></pre>Yojihito: <pre><p>Why not just use <a href="mailto:sql@1.doSomething" rel="nofollow">sql@1.doSomething</a>() and <a href="mailto:sql@2.doAnotherThing" rel="nofollow">sql@2.doAnotherThing</a>()?</p></pre>danredux: <pre><p>Because you want to simplify the common case, always.</p>
<p>Importing a version should, by default, go to a simple namespace.</p>
<p>If you wanted to import both versions, you could import them with a name like "sqlV1" and "sqlV2".</p></pre>agentargo: <pre><p>I'd love to read those chains if you have links to them.</p>
<p>The case where you have two branchs and each import a different version. I'd argue it's even more clear at merge time if you have to explicitly resolve the conflict to make sure you match the correct API.</p>
<p>The other case being you literally have two import in the same file with two different versions. That seems like it should be a compiler error unless you explicitly rename the imports</p>
<p>So this is a compiler error</p>
<pre><code>import (
"database/sql@1"
"database/sql@2"
)
</code></pre>
<p>and this being OK</p>
<pre><code>import (
sql_1 "database/sql@1"
sql_2 "database/sql@2"
)
</code></pre>
<p>Again maybe I'm missing something here that is covered in the mailing list, but that behavior seems totally reasonable to me.</p>
<p>Other languages handle the versioning outside of the code and pip requirements would throw an error if you tried to import a lib twice. Having the git path linked creates a bit of a misnomer to me if you can only reference head. I'd say that the import should be just the name and the external version management tool should define the location.</p>
<p>EDIT:</p>
<p>Found this thread <a href="https://groups.google.com/forum/#!topic/golang-dev/nMWoEAG55v8%5B1-25%5D" rel="nofollow">https://groups.google.com/forum/#!topic/golang-dev/nMWoEAG55v8%5B1-25%5D</a></p></pre>gdey: <pre><p>It's because the import paths are opaque to the go compiler. There are projects that provide you with versioning. <a href="http://labix.org/gopkg.in" rel="nofollow">gopkg.in</a> is a service that allows you to have stable versioned packages. </p>
<p>For example the YAML package is released this way.
gopkg.in/yaml.v1 — get's you version one of the yaml package. And because of the way imports work, the package name is <em>yaml</em>.</p></pre>agentargo: <pre><p>Isn't the definition of an opaque pointer to hide implementation details? So if the name is opaque, the library loader could choose to interpret the path with the @ symbol to point to branch/tag/commit. I could be misinterpreting that though.</p>
<p>This seems like such a hack to create a URL with an implicit version that points to the correct commit.</p></pre>
