On Wed, Aug 20, 2014 at 12:29 AM, Kapil Thangavelu
kapil.thangav...@canonical.com wrote:
hmm.. there's three distinct threads here.
default-hook - charms that do so symlink 0-100% - to one hook.. in
practice everything, sometimes minus install (as the hook infrastructure
needs pkgs).. and
I'm not attempting to cause trouble here - I just want to make sure I
understand the feature - and what effects it might have.
It sounds like any implementation of the default-hook would need to start
with something like: (pseudo-bash)
if JUJU_HOOK_NAME == start
//run start
else if
On Wed, Aug 20, 2014 at 10:46 AM, Matthew Williams
matthew.willi...@canonical.com wrote:
Any default-hook that deviated from this pattern could find itself being
run multiple times in succession - I wonder if that might be confusing/
unexpected to a charm author?
It'll run multiple times in
On Wed, Aug 20, 2014 at 5:46 AM, Matthew Williams
matthew.willi...@canonical.com wrote:
if JUJU_HOOK_NAME == start
//run start
else if JUJU_HOOK_NAME == config-changed
//run config-changed
else if JUJU_HOOK_NAME == stop
//run stop
else
//unknown hook
exit 1
fi
I'd expect the else
On Wed, Aug 20, 2014 at 11:08 AM, William Reade
william.re...@canonical.com wrote:
On Wed, Aug 20, 2014 at 10:46 AM, Matthew Williams
matthew.willi...@canonical.com wrote:
Gustavo's observation about hooks that the charm might no know about yet
means that the else clause is absolutely
On Wed, Aug 20, 2014 at 11:16 AM, Nate Finch nate.fi...@canonical.com wrote:
Anyone who has ever written a switch statement should be used to putting in
a default clause for something I don't expect... I don't think it should
be a big deal.
Some charms mentioned in this thread miss the switch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-08-20 10:50 AM, Nate Finch wrote:
If the special hook file is called default-hook, it makes those
single-script charms seem like less of a hack than if the single
file is called missing-hook. It would also makes more sense to a
new charm
On Wed, Aug 20, 2014 at 11:46 AM, Gustavo Niemeyer gust...@niemeyer.net
wrote:
People must be aware that there
is a multitude of events dispatched to that one executable,
potentially with events they do not expect, and they must be aware
that by creating a different hook they will prevent
On Wed, Aug 20, 2014 at 3:45 PM, Nate Finch nate.fi...@canonical.com wrote:
Here's a proposal that is much simpler: we add a flag to the charm metadata,
called something like single_hook. When single_hook is true, all hook
events run a file called default-hook (or whatever we want to call it,
In an effort to make sure that dependencies.tsv is actually correct, the
tests in github.com/juju/juju now run godeps -t ./... and compare its
output to dependencies.tsv. The test looks for godeps first in the $PATH,
and then in the first $GOPATH/bin. If it is not found, it currently skips
the
On Wed, Aug 20, 2014 at 5:05 PM, Nate Finch nate.fi...@canonical.com wrote:
I think to answer most of these questions, we need more information about
what the existing charms do, and input from the charmers themselves.
Here's the info from Marco: http://pastebin.ubuntu.com/8100649/
Thanks.
On 21/08/14 02:50, Nate Finch wrote:
I would expect a lot of people will implement their charms as a single
script (especially given the number of charms we've seen implemented
that way even with minimal support for it). If the special hook file is
called default-hook, it makes those
H. The test fails for me.
FAIL: dependencies_test.go:42: dependenciesTest.TestGodepsIsRight
dependencies_test.go:77:
...
dependencies_test.go:70:
c.Fatal(string(out))
... Error: godeps: no version control system found for
/usr/lib/go/src/pkg/bufio
godeps: no version control system
What happens when you run godeps normally?
It should ignore the std lib stuff, but I don't actually know how that's
implemented.
On Aug 20, 2014 8:02 PM, Ian Booth ian.bo...@canonical.com wrote:
H. The test fails for me.
FAIL: dependencies_test.go:42: dependenciesTest.TestGodepsIsRight
I run godeps all the time as I switch between 1.20 and master. It Just Works.
On 21/08/14 10:12, Nate Finch wrote:
What happens when you run godeps normally?
It should ignore the std lib stuff, but I don't actually know how that's
implemented.
On Aug 20, 2014 8:02 PM, Ian Booth
All the test does is run godeps -t ./... It looks for godeps in the path
first and then looks in gopath/bin. Do you maybe have a version in your
path that is old?
On Aug 20, 2014 8:15 PM, Ian Booth ian.bo...@canonical.com wrote:
I run godeps all the time as I switch between 1.20 and master. It
Don't think so
ian@wallyworld:~$ which godeps
/home/ian/juju/go/bin/godeps
ian@wallyworld:~$ ls -l `which godeps`
-rwxrwxr-x 1 ian ian 4821160 Aug 15 19:12 /home/ian/juju/go/bin/godeps
On 21/08/14 10:20, Nate Finch wrote:
All the test does is run godeps -t ./... It looks for godeps in the
And running godeps -t ./... Didn't give the same error?
On Aug 20, 2014 8:26 PM, Ian Booth ian.bo...@canonical.com wrote:
Don't think so
ian@wallyworld:~$ which godeps
/home/ian/juju/go/bin/godeps
ian@wallyworld:~$ ls -l `which godeps`
-rwxrwxr-x 1 ian ian 4821160 Aug 15 19:12
Ah yes godeps -t ./... fails the same way.
But I never run that.
I just run godeps -u dependencies.tsv
to update the revs of the imported libs as I switch juju-core branches.
On 21/08/14 10:30, Nate Finch wrote:
And running godeps -t ./... Didn't give the same error?
On Aug 20, 2014 8:26 PM,
The point of the test is that developers *don't* run godeps. That's the
problem. The original email noted that our dependencies.tsv in master was
wrong. It's not the first time this has happened. I've also seen many
developers wonder why things were broken when it was just godeps needing to
be
On 21/08/14 11:42, Nate Finch wrote:
The point of the test is that developers *don't* run godeps. That's the
Well they *should*. If they don't why not? Is it not documented well enough?
It's explicitly mentioned in the CONTRIBUTING doc.
problem. The original email noted that our
21 matches
Mail list logo
