Our current idea is to support multiple ways of installing extensions. One of them will, of course, be by including them in the CSAR file (which can be done in various ways: Python source code, wheels, wagons, etc.). We want to standardize all extensions with a single well-defined entry point.
On Wed, Dec 6, 2017 at 4:58 PM, Vaishnavi K.R <[email protected]> wrote: > Hi Tal, > > > Good that this has been considered. > > As all the three entities are mere python modules, it is good to have a > common loading mechanism. > > But will there be any major change in the existing way of loading plugins > and using the same in the service template? > > > Thanks, > > /Vaish > > ________________________________ > From: Tal Liron <[email protected]> > Sent: Wednesday, December 6, 2017 7:27:02 PM > To: [email protected] > Subject: Re: Loading custom workflows > > Great question, and it was asked very recently on this list ... > > There is a need for a unified way to dynamically load > extensions/plugins/workflows from CSAR files as well as other places. We > are trying to come with a good, forward-looking architectural design for > this loading mechanism. I will provide an update on this in the next few > days. > > On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R <[email protected]> > wrote: > > > Hi, > > > > > > I tried using the custom workflow support provided by ARIA. > > > > In the current ARIA, the custom workflows are directly imported as python > > modules. > > > > It looks like it is loading the python modules that are bundled along > with > > the service template in CSAR. > > > > > > Also I could see that you have plans to load it as how the plugins are. > > > > Is anyone working on this? > > > > Will the workflows be packaged as wagon archives and installed? > > > > Will they be referred in the service template with the same convention as > > plugins? > > > > > > Thanks, > > > > /Vaish > > >
