On 7 April 2016 at 10:17, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 7 April 2016 at 16:03, roger peppe <roger.pe...@canonical.com> wrote: >> On 7 April 2016 at 09:38, Tim Penhey <tim.pen...@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. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
