Follow up - "Missing contrib.amulet in charm-helpers-hooks"

As a follow up to my earlier post "Missing contrib.amulet in charm-helpers-hooks” I want to clarify a few things, as well as hopefully get to the bottom of some hook errors I am experiencing. Earlier, I mentioned that I thought I had found the cause of my hook errors. I realize now that what

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

The one thing I don't think bash aliases give you is proper handling of nested subcommands. Can you easily do "juju st" in a bash alias? or does it have to become "juju-st" ? I think the caveats around people aliasing their way out of clumsiness in the tool is actually something to pay close

Fwd: [charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

Hi Cory Thanks for the explanation. Is there a way to override the scope of the http relation without forking the interface? Kind regards Merlijn 2015-10-26 18:21 GMT+01:00 Cory Johns : > Merlijn, > > You'll note that the docs for auto_accessors >

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

You can accomplish most of this with the existing plugin system. You can't override existing commands, but you can easily create thin wrappers around them with your desired default args, and given the discussion around --no-aliases, it seems like this is actually a benefit. And plugins provide

Re: [charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

Merlijn, Unfortunately, the correct solution for the issue with the HTTP interface layer is to change how the requires side works a bit. I went ahead and made those changes and moved the repo (with Ben's permission) to https://github.com/juju-solutions/interface-http (which will also allow

charm license requirements with multi-licensed payloads

Hi folks, Our big data charms (apache licensed) deploy Hadoop (apache licensed). Hadoop supports various compression codecs, with one of the more popular being lzo. lzo is GPLv2 licensed and therefore not distributed with Hadoop. As a charm author, what is my licensing obligation if I want my

Re: charm license requirements with multi-licensed payloads

Hey Kevin, When you write a charm and include a copyright file, what you are licensing are the lines of code that you write in the charm, not the software itself. You may choose any license you want. If you want to specify the license each piece of software uses, you can do so in the README

Re: charm license requirements with multi-licensed payloads

Thanks, José! I was curious about this too. A follow-up on this question: I have a Charm repo that includes Charms from different sources with patches. Some of these Charms are licensed differently, some require copyleft and some don't. Now, I do it

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

I can't help but draw parallels to the plugin system. There was considerable resistance to adding the ideas of plugins to Juju. It was added complexity that no one needed and could be done simply using existing executable scripts, like juju-foo. Tim On 28/10/15 07:33, Cory Johns wrote: > You

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thank you! Aaron On 2015-10-26 09:22 PM, Tim Penhey wrote: > On 24/10/15 04:05, Aaron Bentley wrote: >> bzr has a similar feature, but the problem with such a feature is >> that it can break scripts that expect the normal behaviour. >> That's why

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

You're not selling me on this ;) On Tue, Oct 27, 2015, 4:01 PM Tim Penhey wrote: > I can't help but draw parallels to the plugin system. > > There was considerable resistance to adding the ideas of plugins to > Juju. It was added complexity that no one needed and

Re: charm license requirements with multi-licensed payloads

That is right. When you do a patch and include it inside a charm, what you are doing is a contribution to the pre-existing code, hence inheriting the license from another charm. If it doesn't have a license and it's been released, I would assume a public domain license until a license is

Re: Follow up - "Missing contrib.amulet in charm-helpers-hooks"

James, Some responses in line: On 10/26/2015 11:38 PM, James Beedy wrote: As a follow up to my earlier post "Missing contrib.amulet in charm-helpers-hooks” I want to clarify a few things, as well as hopefully get to the bottom of some hook errors I am experiencing. Earlier, I mentioned that