Re: move towards using gopkg.in

2014-07-08 Thread roger peppe
On 8 July 2014 03:23, Gustavo Niemeyer gust...@niemeyer.net wrote: On Mon, Jul 7, 2014 at 10:49 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: On Mon, Jul 7, 2014 at 8:49 PM, David Cheney david.che...@canonical.com wrote: I don't want to introduce another thing to break CI, we already

Re: move towards using gopkg.in

2014-07-08 Thread Nate Finch
+1 for stable APIs and versioned import statements. If we're worried about the fact that gopkg.in is run by some random guy* then we're more than capable of running our own redirector on Canonical's infrastructure. Gopkg.in is open source, so we can easily get ours up and running with just a

move towards using gopkg.in

2014-07-07 Thread roger peppe
I think it would be a good idea if we moved towards defining stable APIs, particularly for repositories outside github.com/juju/juju itself. In particular, I hope we can make go get work without people needing to jump through the godeps hoop. This is a particular issue as we move towards having

Re: move towards using gopkg.in

2014-07-07 Thread Tim Penhey
On 08/07/14 09:00, Ian Booth wrote: gopkg.in is a decent solution to this problem, I believe, and a good direction to head in general. After discussion with (and approval by) several juju-core members, we have pushed the new API to gopkg.in/juju/charm.v2 (the code now lives in the v2 branch

Re: move towards using gopkg.in

2014-07-07 Thread roger peppe
On 7 Jul 2014 22:03, Tim Penhey tim.pen...@canonical.com wrote: On 08/07/14 09:00, Ian Booth wrote: gopkg.in is a decent solution to this problem, I believe, and a good direction to head in general. After discussion with (and approval by) several juju-core members, we have pushed the

Re: move towards using gopkg.in

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 6:00 PM, Ian Booth ian.bo...@canonical.com wrote: I'm somewhat wary of depending on an another unknown third party website being That's hilarious. I haven't been pushing for its usage on juju, and I'm still not the one actively pushing it, but that's a pretty bad

Re: move towards using gopkg.in

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 7:18 PM, Ian Booth ian.bo...@canonical.com wrote: It wasn't mean to be funny. I'm unsure why it's a bad argument. It's quite prudent to ensure that critical infrastructure on which our development depends meets expectations with regard to uptime, reliability etc (a case

Re: move towards using gopkg.in

2014-07-07 Thread Ian Booth
On 08/07/14 08:32, Gustavo Niemeyer wrote: On Mon, Jul 7, 2014 at 7:18 PM, Ian Booth ian.bo...@canonical.com wrote: It wasn't mean to be funny. I'm unsure why it's a bad argument. It's quite prudent to ensure that critical infrastructure on which our development depends meets expectations

Re: move towards using gopkg.in

2014-07-07 Thread Gustavo Niemeyer
On Mon, Jul 7, 2014 at 8:49 PM, David Cheney david.che...@canonical.com wrote: I don't want to introduce another thing to break CI, we already pull from github which is bad enough, but going via gopkg.in introduces an additional point of failure which can further reduce the already bullet

Re: move towards using gopkg.in

2014-07-07 Thread Tim Penhey
On 08/07/14 13:49, Gustavo Niemeyer wrote: go list -f '{{range .Deps}}{{printf %s\n .}}{{end}}' | grep gopkg.in | sort -u | sed 's/\.v[0-9]\+$/\.vN/' | uniq -c | sed '/ 1 /d' Yay pipes !?!? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: