New juju in ubuntu

[Stuart Bishop]

On 7 April 2016 at 16:46, roger peppe <roger.peppe at canonical.com> wrote:
> On 7 April 2016 at 10:17, Stuart Bishop <stuart.bishop at canonical.com> wrote:
>> On 7 April 2016 at 16:03, roger peppe <roger.peppe at canonical.com> wrote:
>>> On 7 April 2016 at 09:38, Tim Penhey <tim.penhey at canonical.com> wrote:
>>>> We could probably set an environment variable for the plugin called
>>>> JUJU_BIN that is the juju that invoked it.
>>>>
>>>> Wouldn't be too hard.
>>>
>>> How does that stop old plugins failing because the new juju is trying
>>> to use them?
>>>
>>> An alternative possibility: name all new plugins with the prefix "juju2-" rather
>>> than "juju".
>>
>> I've opened https://bugs.launchpad.net/juju-core/+bug/1567296 to track this.
>>
>> Prepending the $PATH is not hard either - just override the
>> environment in the exec() call.
>>
>> The nicest approach may be to not use 'juju1', 'juju2' and 'juju' but
>> instead just 'juju'. It would be a thin wrapper that sets the $PATH
>> and invokes the correct binary based on some configuration such as an
>> environment variable. This would fix plugins, and lots of other stuff
>> that are about to break too such as deployment scripts, test suites
>> etc.
>
> There are actually two problems here. One is the fact that plugins
> use the Juju binary. For that, setting the PATH might well be the right thing.
>
> But there's also a problem with other plugins that use the Juju API
> directly (they might be written in Go, for example) and therefore
> implicitly assume the that they're talking to a juju 1 or juju 2 environment.
> Since local configuration files have changed and the API has changed, it's
> important that a plugin written for Go 1 won't be invoked by a juju 2
> binary.

If juju 2.x changed the plugin prefix from juju- to juju2-, that would
also solve the issue of juju 2.x specific plugins showing up in juju
1.x's command line help and vice versa.

-- 
Stuart Bishop <stuart.bishop at canonical.com>