Re: move towards using gopkg.in
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 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 ridden credibility of our CI.
Again, gopkg.in sits in a reliable deployment, with a provable track record.
I also don't want to start introducing versioned import paths into
Juju without serious discussion of how to prevent two different
versions of a package transitively.
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'
A bit faster and more correct (picks subpackages too):
go list -f '{{range .Deps}}{{printf %s\n .}}{{end}}'
| sed -n 's,\(gopkg.in/.*\.v\)[0-9]\+.*$,\1N,p' | uniq -u -D
go list -f '{{join \n .Deps}}'
is slightly more compact. These days, I usually use
my showdeps (code.google.com/p/rog-go/cmd/showdeps)
command for this kind of thing - it's easier to type,
and makes it easy to find testing dependencies too.
FWIW, govers (see launchpad.net/govers) should
work fine for updating versioned import paths.
For instance, running:
govers gopkg.in/juju/charm.v3
inside github.com/juju/juju will update all import
paths to use juju/charm.v3. More importantly,
it also checks that no package *outside* juju/juju
is using the original version.
Gustavo's little shell script is more comprehensive
in that respect, but doesn't help when a package
first moves to gopkg.in.
cheers,
rog, who must really move all his stuff to github some time.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: move towards using gopkg.in
+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 little of our own work.
This is the Right Way™ to make sure our code is reliable so that people who
work with our code aren't constantly having their code broken because we
change our APIs constantly. The fact that we don't version the packages
right now means that we don't really care if we break the APIs, so we break
them all the time.
On Tue, Jul 8, 2014 at 3:02 AM, roger peppe roger.pe...@canonical.com
wrote:
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 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 ridden credibility of our CI.
Again, gopkg.in sits in a reliable deployment, with a provable track
record.
I also don't want to start introducing versioned import paths into
Juju without serious discussion of how to prevent two different
versions of a package transitively.
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'
A bit faster and more correct (picks subpackages too):
go list -f '{{range .Deps}}{{printf %s\n .}}{{end}}'
| sed -n 's,\(gopkg.in/.*\.v\)[0-9]\+.*$,\1N,p' | uniq -u -D
go list -f '{{join \n .Deps}}'
is slightly more compact. These days, I usually use
my showdeps (code.google.com/p/rog-go/cmd/showdeps)
command for this kind of thing - it's easier to type,
and makes it easy to find testing dependencies too.
FWIW, govers (see launchpad.net/govers) should
work fine for updating versioned import paths.
For instance, running:
govers gopkg.in/juju/charm.v3
inside github.com/juju/juju will update all import
paths to use juju/charm.v3. More importantly,
it also checks that no package *outside* juju/juju
is using the original version.
Gustavo's little shell script is more comprehensive
in that respect, but doesn't help when a package
first moves to gopkg.in.
cheers,
rog, who must really move all his stuff to github some time.
--
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
Re: move towards using gopkg.in
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 at github.com/juju/charm). The changeover has been no problem. We have been able to change the charm store and juju-core at our leisure, and we have avoided knowingly breaking any external code too. It has been pointed out to me that we have not raised this issue on the mailing list yet. This is me doing that :-) If there are any people that think that this is a bad idea, or that we should be doing it differently, please speak up now. I'm somewhat wary of depending on an another unknown third party website being available for our stuff to work. Of course, we also depend already on github and launchpad etc etc so maybe the point is moot. I still can't see how we can do away with godeps. The gopkg.in solution may solve the api versioning issue at a macro level, but without godeps we still won't get repeatable builds, which is a key requirement for proper configuration management. I agree. Godeps (or similar alternative tool) is still needed and orthogonal to the versioned API imports. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: move towards using gopkg.in
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 new API to gopkg.in/juju/charm.v2 (the code now lives in the v2 branch at github.com/juju/charm). The changeover has been no problem. We have been able to change the charm store and juju-core at our leisure, and we have avoided knowingly breaking any external code too. It has been pointed out to me that we have not raised this issue on the mailing list yet. This is me doing that :-) If there are any people that think that this is a bad idea, or that we should be doing it differently, please speak up now. I'm somewhat wary of depending on an another unknown third party website being available for our stuff to work. Of course, we also depend already on github and launchpad etc etc so maybe the point is moot. I still can't see how we can do away with godeps. The gopkg.in solution may solve the api versioning issue at a macro level, but without godeps we still won't get repeatable builds, which is a key requirement for proper configuration management. I agree. Godeps (or similar alternative tool) is still needed and orthogonal to the versioned API imports. I agree too. Both tools have their role to play. As for additional dependencies on gopkg.in, we are already committed to using some of Gustavo's repositories, which have already moved to using that root, so I don't think it will be much of an additional problem for us to use it ourselves. cheers, rog. Tim -- 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
Re: move towards using gopkg.in
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 argument to raise here. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: move towards using gopkg.in
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 in point being the recent issue with an out of date certificate or so I was told). Sorry if the question caused any offence. I raised the question totally independent of that fact that someone within Canonical had set up the site. You can't both say that it is totally independent from someone next to you being responsible for it, and that it's about being an unknown third party. If your worries are about reliability, there is public track record with the uptime since it was put online (http://stats.pingdom.com/r29i3cfl66c0), and that uptime is supported by replicated deployments across separate cities with automatic failover. Any other concerns? gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: move towards using gopkg.in
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 with regard to uptime, reliability etc (a case in point being the recent issue with an out of date certificate or so I was told). Sorry if the question caused any offence. I raised the question totally independent of that fact that someone within Canonical had set up the site. You can't both say that it is totally independent from someone next to you being responsible for it, and that it's about being an unknown third party. I can see how that may have been misinterpreted. I meant the hosting infrastructure of the site, not the person who deployed it. If your worries are about reliability, there is public track record with the uptime since it was put online (http://stats.pingdom.com/r29i3cfl66c0), and that uptime is supported by replicated deployments across separate cities with automatic failover. Any other concerns? No, thanks for clarifying. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: move towards using gopkg.in
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 ridden credibility of our CI.
Again, gopkg.in sits in a reliable deployment, with a provable track record.
I also don't want to start introducing versioned import paths into
Juju without serious discussion of how to prevent two different
versions of a package transitively.
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'
I am NOT LGTM on any change that introduces gopkg.in redirected import
paths until the issue above is resolved.
Okay, that's done.
gustavo @ http://niemeyer.net
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: move towards using gopkg.in
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:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
