This is indeed the situation right now, but we're unhappy with it and it may be improved soon.
On Fri, Dec 8, 2017 at 12:05 AM, Vaishnavi K.R <[email protected]> wrote: > Hi Tal, > > > The loading of the python modules with python functions for workflows > happens when the module is in PYTHONPATH. > > But I could also see that, the absolute path of the resource storage with > the service template ID is added to sys.path to make it available for > python. > > This facilitates the loading of modules from CSAR, provided the modules > are present in the root directory of the CSAR. > > Am I right? > > > Thanks, > > /Vaish > > ________________________________ > From: Tal Liron <[email protected]> > Sent: Thursday, December 7, 2017 8:51:49 PM > To: [email protected] > Subject: Re: Loading Custom Workflows from CSAR > > Actually, the current implementation does not use the CSAR: it expects that > the Python function (decorated by @workflow) would be somewhere in the > Python path, and we are currently missing a CSAR code-loading mechanism. > > We do not expect the @workflow function structure to change in any way, so > I think you can feel confident about writing custom workflows in this > matter. What might change slightly in the near future is how to package the > .py file. > > > On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon < > [email protected]> wrote: > > > Hi > > While the investigation is on-going, I need to double check what can be > > done today. > > But I guess how it is done today might change as well (?) > > Based on our analysis of the latest code base, the loading of the custom > > workflows today is from CSAR only. > > Please advise. > > > > -Steve > > > > -----Original Message----- > > From: Tal Liron [mailto:[email protected]] > > Sent: Tuesday, November 28, 2017 2:06 PM > > To: [email protected] > > Subject: Re: Loading Custom Workflows from CSAR > > > > Thanks, Steve. We don't have a JIRA for this right now, but we do intend > > to have a way to include "plugins" in a CSAR and have them automatically > > installed. A "plugin" is basically a Python extension to ARIA that can be > > loaded at runtime and contained per service. > > > > This is part of our current general work trying to find a good design for > > plugins generally, and will likely result in a JIRA epic with several > > issues. At this time, I don't think it's worth created this epic if we > > don't have a plan. > > > > The design will likely be inspired by the plugin design in Cloudify, from > > which we grabbed our seed code. However, there is room for some > > re-imagination especially as pertains TOSCA-specific issues. > > > > On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon < > > [email protected]> wrote: > > > > > Hi > > > As far as I know the implementation string associated with the > > > aria.Workflow type must call or execute a Python function (using the > > > dot > > > notation) that is stored in ARIA, like a plugin. > > > When will it be possible to refer to a .py file stored in the CSAR > > > instead? > > > Do you have any Jira for this enhancement? > > > > > > Regards > > > Steve B > > > > > >
