just as it fails for many other projects.. etcd, docker, serf, consul, etc... most larger projects are going to run afoul of trying to do cowboy dependency management and adopt one of the extant tools for managing deps and have a non standard install explained to users in its readme, else its vendoring its deps.
-k On Fri, Jun 6, 2014 at 5:05 PM, Nate Finch <nate.fi...@canonical.com> wrote: > (Resending since the list didn't like my screenshots) > > https://twitter.com/beyang/statuses/474979306112704512 > > https://github.com/juju/juju/issues/43 > > Any tooling that exists for go projects is going to default to doing "go > get". Developers at all familiar with go, are going to use go get. > > People are going to do > > go get github.com/juju/juju > > and it's going to fail to build, and that's a terrible first impression. > > Yes, we can update the README to tell people to run godeps after running > go get, and many people are not going to read it until after they get the > error building. > > Here's my suggestion: > > We make go get work on trunk and still use godeps (or whatever) for > repeatable builds of release branches. > > There should never be a time when tip of trunk and all dependent repos > don't build. This is exceedingly easy to avoid. > > Go crypto (which I believe is what is failing above) is one of the few > repos we rely on that isn't directly controlled by us. We should fork it > so we can control when it updates (since the people maintaining it seem to > not care about making breaking API changes). > -Nate > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
