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. Tim On 07/04/16 17:25, Stuart Bishop wrote: > On 7 April 2016 at 03:55, Marco Ceppi <marco.ce...@canonical.com> wrote: >> >> On Wed, Apr 6, 2016 at 10:07 AM Stuart Bishop <stuart.bis...@canonical.com> >> wrote: >>> >>> On 5 April 2016 at 23:35, Martin Packman <martin.pack...@canonical.com> >>> wrote: >>> >>>> The challenge here is we want Juju 2.0 and all the new functionality >>>> to be the default on release, but not break our existing users who >>>> have working Juju 1.X environments and no deployment upgrade path yet. >>>> So, versions 1 and 2 have to be co-installable, and when upgrading to >>>> xenial users should get the new version without their existing working >>>> juju being removed. >>>> >>>> There are several ways to accomplish that, but based on feedback from >>>> the release team, we switched from using update-alternatives to having >>>> 'juju' on xenial always be 2.0, and exposing the 1.X client via a >>>> 'juju-1' binary wrapper. Existing scripts can either be changed to use >>>> the new name, or add the version-specific binaries directory >>>> '/var/lib/juju-1.25/bin' to the path. >>> >>> How do our plugins know what version of juju is in play? Can they >>> assume that the 'juju' binary found on the path is the juju that >>> invoked the plugin, or is there some other way to tell using >>> environment variables or such? Or will all the juju plugins just fail >>> if they are invoked from the non-default juju version? >> >> >> You can invoke `juju version` from within the plugin and parse the output. >> That's what I've been doing when I need to distinguish functionality. > > That seems fine if you are invoking the plugin from the default > unnumbered 'juju'. But running 'juju2 wait' will mean that juju-wait > will be executing juju 1.x commands and fail. And conversely running > 'juju1 wait' will invoke juju 2.x and probably fail. > > I think the plugin API needs to be extended to support allowing > multiple juju versions to coexist. An environment variable would do > the trick but require every plugin to be fixed. Altering $PATH so > 'juju' runs the correct juju would allow existing plugins to run > unmodified (the bulk of them will work with both juju1 and juju2, > since the cli is similar enough that many plugins will work > unmodified. > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
