On Aug 6, 2014, at 7:43 AM, Kim Manning <kmann...@gmx.com> wrote:
> Sorry, was a bit unclear in my original email. The base-component thing is
> not an issue. As an aside, it hadn't occurred to me that the launch functions
> were designed only for command line args. I'd just been calling the ones for
> my sub-components directly from the base. Seems to work.
>
> Anyway - yes, my main issue is that I don't want to use pox.py. Thanks for
> the quick suggestions - I played around a bit with boot.py and came up with
> something that seemed to work well. I let boot() take a dict of components in
> the format that _do_launch() builds at the start, and split out the argv
> parsing from _do_launch for when I do want to use pox.py and pass in a real
> argv list. So I can simply write something like(using similar examples to
> before)
>
> from pox.boot import boot
> from mypackage.function1 import callback
> args = {'component1': [ {'callback': callback} ]}
> boot(args)
>
> and end up with the callback function directly in my component1 launch
> function.
Yeah. I think we could actually modify boot()/_do_launch() to just take a list
of strings and callables. Strings would be interpreted as they are now.
Callables would just be called, letting you do whatever you wanted at that
point.
> Still have some issues with pox_options that I didn't think that hard about
> because I don't use them much.
Yeah. I have never liked them and try to not introduce new ones. The trend
has actually been to eliminate them.
> Confession time: I'd really like to discuss this further, with actual code,
> but I don't know the etiquette for posting code to dev mailing lists. Help a
> student out?
At least on this list, posting code is fine. Or posting gists or something and
linking to them. Or pointing at a repo. Whatever works. For long
discussions, it may make sense to do it on github where you can easily comment
on lines, formatting is preserved, it doesn't make noise for disinterested
parties, etc.
-- Murphy
> On 06/08/14 01:47, Murphy McCauley wrote:
>> The only purpose of the launch function is to facilitate writing components
>> that take arguments from the commandline. If you don't want that -- just
>> don't use it.
>>
>> It sounds like you'd be happy with plain-old-Python, and what you really
>> want is just to write a component which spans multiple files (modules)?
>> Just have one file as the "component interface" (has a launch function),
>> which then has a bunch of import statements for the multiple other modules
>> you use and accesses things in them (read globals, call functions, etc.)
>> directly, as per Python-usual.
>>
>> If the issue is that you don't want to use pox.py to start POX and instead
>> want to embed POX in another application, this is pretty easy in recent
>> versions as long as you're happy with a pretty simple scenario. It's been a
>> while since I've done it, but I think I basically just hacked up boot.boot()
>> to make sense within the context of the app I was embedding into, and passed
>> _do_launch() the name of a module in the "outer" application (it's kind of
>> dumb that it needs to be imported by name, but hasn't been big enough of an
>> issue to do anything about).
>>
>> -- Murphy
>>
>> On Aug 5, 2014, at 5:36 AM, Kim Manning <kmann...@gmx.com> wrote:
>>
>>> Hi Murphy, others,
>>>
>>> It's my understanding (from the wiki, etc) that POX is designed to be
>>> launched from the command line only, with options given to individual
>>> components on the command line as well. The wiki recommends that if you
>>> have multiple components and this is getting unwieldy to create a base
>>> module which launches them all - this is how I currently start POX.
>>>
>>> What I would like to do is pass callbacks to the launch function of each of
>>> the individual components. This is my current method:
>>>
>>> 1) Possible functions are stored in individual modules each containing a
>>> function called "callback" (say)
>>>
>>> 2) From an external-to-POX python script (something like a configuration
>>> script), I specify the callback function I want as a string
>>> ("mypackage.function1")
>>>
>>> 3) I start POX as a separate subprocess, with the string as a component
>>> argument ("pox.py base_component --callback=mypackage.function1")
>>>
>>> 4) In the launch function for base_component, I dynamically import
>>> mypackage.function1 and store the callback() function from it - and use it
>>> from there as required
>>>
>>> ...which is a strange and awkward process to say the least. In my perfect
>>> world I'd be able to start POX, from within my python script, and directly
>>> pass these functions (and potentially other python objects, to keep this
>>> general - essentially all I want is to avoid the conversion to command line
>>> args) to my POX components.
>>>
>>> Not sure what I'm expecting to get out of this email but maybe just
>>> suggestions? Ideas? Am I doing this a very stupid way and there's a simple
>>> solution available right now? More than happy to play with the POX code - I
>>> had a look at pox.boot, briefly, but it seemed quite focused on the argv
>>> idea so would require a bit of work. Maybe something like the boot function
>>> that took, say, a python dict of args?
>>>
>>> Would appreciate any comments you might have.
>>>
>>> -- Kim
>
