How does `go get` know the URL for an import path?

[TR NS]

Is there any documentation on how `go get` figures out the URL of an import path?

Does it have to use trial and error to ping different sources?

Are there any edge cases that would render it unworkable?

Thanks.

[DisposaBoy]

What do you mean? (The import path *is* the url?)

See also http://golang.org/cmd/go/#hdr-Remote_import_path_syntax

 

[Bill Thiede]

There is a table for well known hosts, see:

http://golang.org/src/cmd/go/vcs.go#L533

It can also extract the version control type from meta tags present in an HTML <meta> tag for a domain, see:

http://golang.org/src/cmd/go/vcs.go#L427

I suppose there's always ways to render a system unworkable, are you having a specific problem?

Bill

[Ian Davis]

The source code for the go tool is the best place to look:

 

http://code.google.com/p/go/source/browse/src/cmd/go/vcs.go#569

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

 

[TR NS]

On Tuesday, November 26, 2013 1:11:10 PM UTC-5, Ian Davis wrote:

The source code for the go tool is the best place to look:

 

http://code.google.com/p/go/source/browse/src/cmd/go/vcs.go#569

Thanks all. Very helpful!

Did anyone else no about the `go1` tag? What the heck is that all about?

[Dave Cheney]

It's documented,

http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies

But not very popular

[TR NS]

On Tuesday, November 26, 2013 6:58:21 PM UTC-5, Dave Cheney wrote:

It's documented,

http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies

 

But not very popular

I read that, but I thought I must be missing something. Apparently not. It's a really strange approach. Actually I don't think it's really workable at all.

[Andrew Gerrand]

On 27 November 2013 13:42, TR NS <tran...@gmail.com> wrote:

I read that, but I thought I must be missing something. Apparently not. It's a really strange approach. Actually I don't think it's really workable at all.

I don't think anyone uses that feature.

It was a help when we released Go 1 and updated the world, but now it's not so useful.

Andrew 

[TR NS]

Ah ok. Thanks Andrew.

So can I ask (maybe *beg* is a better word)... I was looking over the `go get` code and it seems like everything that is needed is already in place --it wouldn't take much adjustment to the code, to support an optional tag/branch ref on the `import` statement, e.g.

    import(
        github.com/alice/foo v1.1
    )

That's the only significant missing feature that has me looking to 3rd party dependency tools rather than using `go get`.

And the reason for it is quite simple. When another developer/user downloads my code and builds, I need to be sure they are getting an identical build to mine.

[luz...@gmail.com]

On Wednesday, November 27, 2013 10:40:42 AM UTC+1, TR NS wrote:

support an optional tag/branch ref on the `import` statement, e.g.

    import(
        github.com/alice/foo v1.1
    )

Imports are just directories in the file system, even if some of them might look like code hosting platform URLs. The Go language spec and the compiler don't know anything about the internet, URLs, code hosting platforms or version control systems. I'd argue it should stay that way. How, why, when and by whom these directories are created is a language independent, orthogonal concept that doesn't feel like it needs to or should be addressed via language changes, it can be addressed entirely in tool space. Godeps, for example, reads a separate manifest file.

[Volker Dobler]

Am Mittwoch, 27. November 2013 10:40:42 UTC+1 schrieb TR NS:

So can I ask (maybe *beg* is a better word)... I was looking over the `go get` code and it seems like everything that is needed is already in place --it wouldn't take much adjustment to the code, to support an optional tag/branch ref on the `import` statement, e.g.

    import(
        github.com/alice/foo v1.1
    )

That's the only significant missing feature that has me looking to 3rd party dependency tools rather than using `go get`.

This has been discussed on this mailing list several times

and rejected because it just seems like a good idea (it isn't).

It won't happen.

V.

[TR NS]

The ref would be a part of the directory too. It would have to be. The ref only further refines the path. No need to "know anything about the internet, URLs, code hosting platforms or version control systems" -- except for `go get` of course, which already does.

[luz...@gmail.com]

On Wednesday, November 27, 2013 1:16:33 PM UTC+1, TR NS wrote:

The ref would be a part of the directory too. It would have to be. The ref only further refines the path.

If it's part of the directory then it belongs inside the quotes. No need to alter the grammar of the language.

except for `go get` of course, which already does.

Yes, "go get" is not part of the Go language. It's just a tool bundled with the gc distribution. gccgo, for example, usually isn't bundled with a "go get". Your proposal looked to me as if it was a language change.

[Morten Siebuhr]

On Wed, Nov 27, 2013 at 10:40 AM, TR NS <tran...@gmail.com> wrote:
>
>
> On Tuesday, November 26, 2013 10:24:52 PM UTC-5, Andrew Gerrand wrote:
>>
>>
>> On 27 November 2013 13:42, TR NS <tran...@gmail.com> wrote:
>>>
>>> I read that, but I thought I must be missing something. Apparently not.
>>> It's a really strange approach. Actually I don't think it's really workable
>>> at all.
>>
>>
>> I don't think anyone uses that feature.
>> It was a help when we released Go 1 and updated the world, but now it's
>> not so useful.
>
>
> Ah ok. Thanks Andrew.
>
> So can I ask (maybe *beg* is a better word)... I was looking over the `go
> get` code and it seems like everything that is needed is already in place
> --it wouldn't take much adjustment to the code, to support an optional
> tag/branch ref on the `import` statement, e.g.
>
> import(
> github.com/alice/foo v1.1
> )
>
> That's the only significant missing feature that has me looking to 3rd party
> dependency tools rather than using `go get`.

I have actually hacked support for that by subverting the existing
support for the semi-magic go1-tag:

https://github.com/msiebuhr/go-tag-test

(I haven't checked if the patch still applies to go1.2, but if not, it
should be simple to fix.)

It currently only supports URLs from Github on the form

github.com/msiebuhr/go-ta...@v0.0.1/

(Where the tag/branch is optional; it is serialised with the
tag/branch on-disk.)

> And the reason for it is quite simple. When another developer/user downloads
> my code and builds, I need to be sure they are getting an identical build to
> mine.

Yup. At least this approach seem to work quite fine for Node.js and
Python (the two I've been working a lot with). I understand that
Bower, Maven and Perl also do it roughly that way.

I have played with vendoring (importing the upstream package into your
tree) but the lack of file-relative imports[0] makes it difficult to
write packages that support this nicely. There are tools to do this
for you, but there doesn't seem to be any community consensus about
which of those is the right one (and most of them are mutually
incompatible).

[0] File-relative imports *does* work in *some* cases. I haven't yet
had the time to dig into it.

--
Morten Siebuhr