FAQ
Gophers,

I've just spent the best part of an unpleasant and frustrating hour trying
to build some Go software. I'm still no closer to actually getting started
on my prototype and tests despite having been already writing Go programs
in the same environment for a few weeks.

I seem to have hit some kind of networking issue with trying to `go get`
any package that has a build dependency hosted on some kind of third party
version service called "gopkg.in". Now in all likelyhood there's some issue
with the company network or the development environment which is causing
the network timeouts with `go get` requests to the gopkg.in domain, but
that's not what's causing my frustration.

What *is* causing my frustration is the endless run around I'm having to do
by first of all finding the actual canonical repositories in the dependency
chain, forking them, updating their import paths to point away from gopkg.in
and then vendoring the whole lot. A problem, I assume, that this third
party service was aiming to help mitigate.

All in all this is causing me way more lost time (which is the number one
way to irritate many developers) than if I simply had to vendor the
packages in the first place. I'm now very much more likely to avoid any
package which imports from a third party version service and I sincerely
doubt I'm not the only one.

Am I in the minority to experience this kind of frustration? Does it really
advance the community by using opaque package import URL's in open code?

Thanks, for putting up with my steam vent!


Cheers the noo,
Graham

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Roger peppe at Nov 17, 2014 at 3:16 pm
    If you have a problem reaching gopkg.in, you can probably
    run the gopkg.in server locally (go get github.com/niemeyer/gopkg -
    it has almost no dependencies), and fix up
    gopkg.in in your /etc/hosts file.

    Disclaimer: I haven't actually tried this, but I'd be interested
    in knowing whether it works for you.
    On 17 November 2014 13:24, Graham Anderson wrote:
    Gophers,

    I've just spent the best part of an unpleasant and frustrating hour trying
    to build some Go software. I'm still no closer to actually getting started
    on my prototype and tests despite having been already writing Go programs in
    the same environment for a few weeks.

    I seem to have hit some kind of networking issue with trying to `go get` any
    package that has a build dependency hosted on some kind of third party
    version service called "gopkg.in". Now in all likelyhood there's some issue
    with the company network or the development environment which is causing the
    network timeouts with `go get` requests to the gopkg.in domain, but that's
    not what's causing my frustration.

    What *is* causing my frustration is the endless run around I'm having to do
    by first of all finding the actual canonical repositories in the dependency
    chain, forking them, updating their import paths to point away from gopkg.in
    and then vendoring the whole lot. A problem, I assume, that this third party
    service was aiming to help mitigate.

    All in all this is causing me way more lost time (which is the number one
    way to irritate many developers) than if I simply had to vendor the packages
    in the first place. I'm now very much more likely to avoid any package which
    imports from a third party version service and I sincerely doubt I'm not the
    only one.

    Am I in the minority to experience this kind of frustration? Does it really
    advance the community by using opaque package import URL's in open code?

    Thanks, for putting up with my steam vent!


    Cheers the noo,
    Graham

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rjeczalik at Nov 17, 2014 at 3:28 pm
    If you trust e.g. github.com more than third-party proxy services (my case
    as well) you could vendor the libraries once using their original remote
    url.

    For gopkg.in I use:

    ~/src/project $ curl -Ss gopkg.in/yaml.v2 | sed -n 's/^.*btn btn-lg
    btn-info" href="http[s]*:\/\/\([^"]*\)".*Source Code.*$/\1/p'
    github.com/go-yaml/yaml/tree/v2
    ~/src/project $ git submodule add git@github.com:go-yaml/yaml.git
    vendor/src/gopkg.in/yaml.v2


    And my GOPATH for "project" looks like:

    GOPATH="$HOME:$HOME/src/project/vendor"

    Obviously go get -u does not work which such vendored packages, but I can
    live with that. After you push your project to e.g. GitHub you have already
    all dependencies as submodules, so no need for go-getting from gopkg.in
    anymore, it's just:

    ~/src $ git clone --recursive git@github:project project

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tamás Gulácsi at Nov 17, 2014 at 4:52 pm
    You can create gopkg.in/... and git clone all needed dependency into a proper Dir. This way go get will work, although not through gopkg.in.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nate Finch at Nov 17, 2014 at 5:38 pm
    Note that the only thing that actually cares that gopkg.in is a url is go
    get. As someone else said, you can just manually create the directory in
    gopath ($GOPATH/src/gopkg.in/foo/bar) and git clone the code from github
    into it.

    Now, yes, this is what vendoring is meant to help alleviate - when you
    can't get to other people's repos. I highly suggest looking at godep as a
    vendoring solution, it is the most well-tested and well-respected tool for
    handling dependencies in Go: https://github.com/tools/godep

    once you have all the dependencies downloaded locally, it's a simple matter
    of doing `godep save -r` and it'll automatically vendor all the
    dependencies in your project, and rewrite all the import paths so they
    reference the vendored location.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Nov 17, 2014 at 5:47 pm
    Hi Graham,

    On Mon Nov 17 2014 at 11:25:06 AM Graham Anderson
    wrote:
    I seem to have hit some kind of networking issue with trying to `go get` any package that has a build dependency hosted on some kind of third party version service called "gopkg.in". Now in all likelyhood
    I'm sorry to hear you having issues downloading content from gopkg.in.

    One thing that may cause a timeout is to use an exceedingly old
    version of git, before it supported redirections. The patch was
    committed to git ~5 years ago, and is available in 1.7.3 and later
    (IIRC).

    https://github.com/git/git/commit/d3334d9c444a22847e7add0f60c2e4a7243c151e

    Another report I got about timeouts turned out to be caused by the
    network of the service that was attempting to use it being
    black-listed by Google (the master of gopkg.in currently lives in
    GCE). If that happens to be the issue you have as well, please let me
    know.
    What *is* causing my frustration is the endless run around I'm having to do by first of all finding the actual canonical repositories in the dependency chain, forking them, updating their import paths to point away from gopkg.in and then vendoring the whole lot. A problem, I assume, that this third party service was aiming to help mitigate.
    No, the service is not trying to help you to fork third-party code in
    any way. It's just as easy (or hard) to do that than with any other Go
    repository, and the same tooling to help the situation work as well
    (godep, godeps, etc).

    If you want to know the problem gopkg.in does help solving, the main
    page at http://gopkg.in has a better explanation than I might
    reproduce here right now.


    Gustavo Niemeyer
    gustavo @ http://niemeyer.net

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Vitor De Mario at Nov 17, 2014 at 6:02 pm

    On Mon, Nov 17, 2014 at 3:47 PM, Gustavo Niemeyer wrote:

    Another report I got about timeouts turned out to be caused by the
    network of the service that was attempting to use it being
    black-listed by Google (the master of gopkg.in currently lives in
    GCE). If that happens to be the issue you have as well, please let me
    know.
    How could I test this? I have the same issue, all 'go get' commands hitting
    gopkg.in hang for me. It stops on the git clone command (as seen using -x
    for go get). I'm using git 2.1.1.

    Same thing seems to be happening for at least one of my teammates so
    there's reason to suspect our network but I'm at a loss to troubleshoot
    this.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • James Bardin at Nov 17, 2014 at 7:06 pm

    On Monday, November 17, 2014 1:02:40 PM UTC-5, Vitor De Mario wrote:

    How could I test this? I have the same issue, all 'go get' commands
    hitting gopkg.in hang for me. It stops on the git clone command (as seen
    using -x for go get). I'm using git 2.1.1.

    Same thing seems to be happening for at least one of my teammates so
    there's reason to suspect our network but I'm at a loss to troubleshoot
    this.
    That really sounds like a git problem, but you can hit the url directly
    with a browser. I feel like there was a regression in git redirect handling
    at one point too, but it was at least year ago when that came up for me.

    Try updating git before anything else.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Vitor De Mario at Nov 17, 2014 at 7:48 pm
    Indeed, I can hit the url with a browser. As for updating git, I did. I was
    on 1.9.x (can't remember exactly) before and updated trying to solve this.

    I've gotten a little bit further: git clone hangs on a "POST
    git-upload-pack" operation, I don't know if this is your issue as well,
    Graham.

    Anyway, thanks for the help, I'm getting too much off topic. This is indeed
    a git problem.
    On Mon, Nov 17, 2014 at 5:06 PM, James Bardin wrote:


    On Monday, November 17, 2014 1:02:40 PM UTC-5, Vitor De Mario wrote:


    How could I test this? I have the same issue, all 'go get' commands
    hitting gopkg.in hang for me. It stops on the git clone command (as seen
    using -x for go get). I'm using git 2.1.1.

    Same thing seems to be happening for at least one of my teammates so
    there's reason to suspect our network but I'm at a loss to troubleshoot
    this.
    That really sounds like a git problem, but you can hit the url directly
    with a browser. I feel like there was a regression in git redirect handling
    at one point too, but it was at least year ago when that came up for me.

    Try updating git before anything else.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Peter Kleiweg at Nov 18, 2014 at 4:51 pm
    You need a very recent version of git. The version of git in many linux distros still in use is too old. (e.g. Debian 6, only two years old.)

    If you write a package that depends on something from gopkg.in, I recommend cloning it, and include it into your package.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Nov 20, 2014 at 7:44 pm
    The git fix was made available in 1.7.3.4, released in 2010-12-15. I
    wouldn't call that very recent.

    On Tue Nov 18 2014 at 2:51:24 PM Peter Kleiweg wrote:

    You need a very recent version of git. The version of git in many linux
    distros still in use is too old. (e.g. Debian 6, only two years old.)

    If you write a package that depends on something from gopkg.in, I
    recommend cloning it, and include it into your package.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Peter Kleiweg at Nov 20, 2014 at 8:58 pm
    Debian 6 has git version 1.7.2.5. Debian 7 is just 18 months old.

    Op donderdag 20 november 2014 20:44:50 UTC+1 schreef Gustavo Niemeyer:

    The git fix was made available in 1.7.3.4, released in 2010-12-15. I
    wouldn't call that very recent.


    On Tue Nov 18 2014 at 2:51:24 PM Peter Kleiweg <pkle...@xs4all.nl
    <javascript:>> wrote:
    You need a very recent version of git. The version of git in many linux
    distros still in use is too old. (e.g. Debian 6, only two years old.)

    If you write a package that depends on something from gopkg.in, I
    recommend cloning it, and include it into your package.

    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Nov 21, 2014 at 1:39 pm
    Debian 6 was released about 4 years ago, in February of 2011. At that time,
    Go would still take one year in development before releasing version 1. If
    you write a package that depends on _that_, I would suggest forking the
    package.


    On Thu Nov 20 2014 at 6:58:39 PM Peter Kleiweg wrote:

    Debian 6 has git version 1.7.2.5. Debian 7 is just 18 months old.

    Op donderdag 20 november 2014 20:44:50 UTC+1 schreef Gustavo Niemeyer:

    The git fix was made available in 1.7.3.4, released in 2010-12-15. I
    wouldn't call that very recent.

    On Tue Nov 18 2014 at 2:51:24 PM Peter Kleiweg wrote:
    You need a very recent version of git. The version of git in many linux
    distros still in use is too old. (e.g. Debian 6, only two years old.)

    If you write a package that depends on something from gopkg.in, I
    recommend cloning it, and include it into your package.

    --
    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/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Meta keule at Nov 18, 2014 at 11:35 am
    I once had an issue with git hanging at 'POST git-upload-pack' that turned
    out
    to be an issue with my MTU
    <http://en.wikipedia.org/wiki/Maximum_transmission_unit> being too small.

    That problem only appeared in certain networks / providers.

    It war hard to track down. I guess some bits have been missing in each
    message...

    Hope that helps.


    Am Montag, 17. November 2014 14:25:03 UTC+1 schrieb Graham Anderson:
    Gophers,

    I've just spent the best part of an unpleasant and frustrating hour trying
    to build some Go software. I'm still no closer to actually getting started
    on my prototype and tests despite having been already writing Go programs
    in the same environment for a few weeks.

    I seem to have hit some kind of networking issue with trying to `go get`
    any package that has a build dependency hosted on some kind of third party
    version service called "gopkg.in". Now in all likelyhood there's some
    issue with the company network or the development environment which is
    causing the network timeouts with `go get` requests to the gopkg.in
    domain, but that's not what's causing my frustration.

    What *is* causing my frustration is the endless run around I'm having to
    do by first of all finding the actual canonical repositories in the
    dependency chain, forking them, updating their import paths to point away
    from gopkg.in and then vendoring the whole lot. A problem, I assume, that
    this third party service was aiming to help mitigate.

    All in all this is causing me way more lost time (which is the number one
    way to irritate many developers) than if I simply had to vendor the
    packages in the first place. I'm now very much more likely to avoid any
    package which imports from a third party version service and I sincerely
    doubt I'm not the only one.

    Am I in the minority to experience this kind of frustration? Does it
    really advance the community by using opaque package import URL's in open
    code?

    Thanks, for putting up with my steam vent!


    Cheers the noo,
    Graham
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Meta keule at Nov 18, 2014 at 11:40 am
    To correct myself: MTU was too large, not to small

    This might help:

    http://stackoverflow.com/questions/26396126/git-ls-remote-hangs-when-using-git-ssh
    http://stackoverflow.com/questions/14123170/git-impossible-to-push-after-add



    Am Montag, 17. November 2014 14:25:03 UTC+1 schrieb Graham Anderson:
    Gophers,

    I've just spent the best part of an unpleasant and frustrating hour trying
    to build some Go software. I'm still no closer to actually getting started
    on my prototype and tests despite having been already writing Go programs
    in the same environment for a few weeks.

    I seem to have hit some kind of networking issue with trying to `go get`
    any package that has a build dependency hosted on some kind of third party
    version service called "gopkg.in". Now in all likelyhood there's some
    issue with the company network or the development environment which is
    causing the network timeouts with `go get` requests to the gopkg.in
    domain, but that's not what's causing my frustration.

    What *is* causing my frustration is the endless run around I'm having to
    do by first of all finding the actual canonical repositories in the
    dependency chain, forking them, updating their import paths to point away
    from gopkg.in and then vendoring the whole lot. A problem, I assume, that
    this third party service was aiming to help mitigate.

    All in all this is causing me way more lost time (which is the number one
    way to irritate many developers) than if I simply had to vendor the
    packages in the first place. I'm now very much more likely to avoid any
    package which imports from a third party version service and I sincerely
    doubt I'm not the only one.

    Am I in the minority to experience this kind of frustration? Does it
    really advance the community by using opaque package import URL's in open
    code?

    Thanks, for putting up with my steam vent!


    Cheers the noo,
    Graham
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 17, '14 at 1:24p
activeNov 21, '14 at 1:39p
posts15
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase