[OPEN-ILS-DEV] OpenSRF 101

Fri Nov 5 11:40:01 EDT 2010

Updated patch looks good.  Much obliged, Bill!

-Mike

On Fri, Nov 5, 2010 at 11:24, Bill Erickson <erickson at esilibrary.com> wrote:
> Thanks for the patches, Michael.
> I've applied the opensrf-py.patch without the path mangling, which should be
> handled with the next patch...
> I created a modified osrf_ctl-sh.patch to take a couple of additional steps:
> 1. copy opensrf.py into the BIN dir during install if python is enabled.
> 2. updated osrf_ctl.sh to avoid attempts at stopping/starting python
> services when python is not enabled for opensrf.
> Eyes appreciated on the patch.  Not being 100% familiar with the autoconf
> bits, it's possible both #1 and #2 could be implemented better.
> Patch: http://dev198.esilibrary.com/~berick/patches/osrf_python_control.patch.txt
> Thanks
> -b
> On Fri, Nov 5, 2010 at 12:56 AM, Michael J. Giarlo
> <leftwing at alumni.rutgers.edu> wrote:
>>
>> Patch w/ DCO tarball attached to this email.  Apologies for newb
>> mistakes -- let me know if I should make any changes.  Patch includes
>> two diffs in opensrf.py, and a bunch of stuff in osrf_ctrl.sh.in to
>> enable python services -- though perhaps these changes should live in
>> a Makefile and should be dependent on the --enable-python option.
>>
>> -Mike
>>
>>
>>
>> On Thu, Nov 4, 2010 at 08:46, Bill Erickson <erickson at esilibrary.com>
>> wrote:
>> >
>> > Hi Michael,
>> > If you want to send your diffs as a patch file (with DCO [1]), I'll
>> > merge
>> > them into OpenSRF trunk in preparation for the 2.0 release.
>> >
>> > -b
>> > [1] http://svn.open-ils.org/trac/ILS/browser/trunk/DCO-1.1.txt
>> >
>> > On Sat, Oct 30, 2010 at 6:23 PM, Michael J. Giarlo
>> > <leftwing at alumni.rutgers.edu> wrote:
>> >>
>> >> Thanks a bunch, Dan; my test Python service is now running.  Thanks
>> >> also to Jeff, who replied with much the same suggestions on my gist.
>> >>
>> >> Some notes below.
>> >>
>> >> On Sat, Oct 30, 2010 at 03:59, Dan Scott <dan at coffeecode.net> wrote:
>> >> >
>> >> > First up: your config settings look pretty good to me. Bravo! One
>> >> > thing
>> >> > to point out, though, is that the Python service needs to be
>> >> > implemented
>> >> > as a module available from sys.path, and the name of the module is
>> >> > what
>> >> > you need to specify as the content of the <implementation> element in
>> >> > the application config section. So I copied osrf_reverse.py to
>> >> > /usr/lib/python2.6/site-packages/. and changed
>> >> > <implementation>osrf.test</implementation> to
>> >> > <implementation>osrf_reverse</implementation>
>> >>
>> >> Aha, that makes sense.  What I did:
>> >>
>> >>  * Added an /opensrf/lib/python directory
>> >>  * Symlinked my osrf_test.py from /opensrf/lib/python into my
>> >> workspace, so I can continue coding in my usual place
>> >>  * Pulled opensrf.py from the source into /opensrf/bin
>> >>  * Tweaked opensrf.py's default path by adding:
>> >>    sys.path.append(os.path.join(os.path.dirname(__file__), "lib",
>> >> "python"))
>> >>
>> >> > Second: to start the Python service, you don't run it directly;
>> >> > instead,
>> >> > you use the Python controller script to run it (similar to how
>> >> > osrf_ctl.sh invokes opensrf-perl.pl to start the Perl services). This
>> >> > controller script can be found in src/python/opensrf.py - we don't
>> >> > install it into /openils/bin/ yet because nobody was using Python in
>> >> > OpenSRF yet - so let's give it a shot with the following (using "-l"
>> >> > assuming that we're pointing to the "<localhost>" set of services) as
>> >> > the opensrf user:
>> >>
>> >> Great.  I also tweaked osrf_ctl.sh to hook into opensrf.py.
>> >>
>> >> Then I noticed some odd behavior re what's returned via
>> >> osrf.set.get('apps').  One key returned in the dict is "#comments",
>> >> which does not contain the 'language' key, so a KeyError exception is
>> >> raised.  Fixed that with the following diff in opensrf.py:
>> >>
>> >> 114c112
>> >> <         if isinstance(svc, dict) and 'language' in svc and
>> >> svc['language'] == 'python':
>> >> ---
>> >> >         if isinstance(svc, dict) and svc['language'] == 'python':
>> >>
>> >>
>> >> > ... this is a painful Python DNS issue that is fortunately nicely
>> >> > documented in the OpenSRF README - see "dnsmasq".
>> >>
>> >> I did indeed run into this, and the stuff in the README worked
>> >> brilliantly.  Huzzah for good documentation!
>> >>
>> >> > YAY! Looks like an off-by-one error on the "n" but
>> >> > otherwise that's what we want.
>> >>
>> >> Yep.  Simplified my reverse_text method to a one liner:
>> >>
>> >>    request.respond(message[::-1])
>> >>
>> >> No more off-by-one.
>> >>
>> >> > However, given an actual user of this
>> >> > code, I'll be happy to put some energy into refining the packaging to
>> >> > (for example) get opensrf.py installed if people choose
>> >> > --enable-python,
>> >> > provide some more examples / test cases, put together some docs, etc.
>> >>
>> >> It's early days yet, but I can see the potential in using OpenSRF for
>> >> what we're about to start prototyping at Penn State.  If so, we're
>> >> pretty gung ho about Python, so we're likely to cross paths again,
>> >> i.e., I think we can help you help us.
>> >>
>> >> Thanks again, Dan & Jeff!
>> >>
>> >> -Mike
>> >>
>> >> P.S. Here are the osrf_ctl.sh diffs, trivial though they are:
>> >>
>> >> 51,53d50
>> >> <     start_python
>> >> <     stop_python
>> >> <     restart_python
>> >> 159,179d155
>> >> < start_python() {
>> >> <     echo "Starting OpenSRF Python";
>> >> <     OPT_LOCAL=""
>> >> <     if [ "$OSRF_HOSTNAME" = "localhost" ]; then
>> >> <       OPT_LOCAL="-l"
>> >> <     fi
>> >> <     opensrf.py -d -p $OPT_PID_DIR -f $OPT_CONFIG -a start_all
>> >> $OPT_LOCAL
>> >> <     return 0;
>> >> < }
>> >> <
>> >> < stop_python() {
>> >> <     echo "Stopping OpenSRF Python";
>> >> <     OPT_LOCAL=""
>> >> <     if [ "$OSRF_HOSTNAME" = "localhost" ]; then
>> >> <       OPT_LOCAL="-l"
>> >> <     fi
>> >> <     opensrf.py -p $OPT_PID_DIR -f $OPT_CONFIG -a stop_all $OPT_LOCAL
>> >> <     sleep 1;
>> >> <     return 0;
>> >> < }
>> >> <
>> >> 223,225d198
>> >> <       "start_python") start_python;;
>> >> <       "stop_python") stop_python;;
>> >> <       "restart_python") stop_python; start_python;;
>> >> 229,234c202,207
>> >> <       "start_osrf") start_perl; start_c; start_python;;
>> >> <       "stop_osrf") stop_perl; stop_c; start_python;;
>> >> <       "restart_osrf") stop_perl; stop_c; stop_python; start_perl;
>> >> start_c; start_python;;
>> >> <       "stop_all") stop_c; stop_perl; stop_python; stop_router;;
>> >> <       "start_all") start_router; start_perl; start_c; start_python;;
>> >> <       "restart_all") stop_c; stop_perl; stop_python; stop_router;
>> >> start_router; start_perl; start_c; start_python;;
>> >> ---
>> >> >       "start_osrf") start_perl; start_c;;
>> >> >       "stop_osrf") stop_perl; stop_c;;
>> >> >       "restart_osrf") stop_perl; stop_c; start_perl; start_c;;
>> >> >       "stop_all") stop_c; stop_perl; stop_router;;
>> >> >       "start_all") start_router; start_perl; start_c;;
>> >> >       "restart_all") stop_c; stop_perl; stop_router; start_router;
>> >> > start_perl; start_c;;
>> >
>> >
>> >
>> > --
>> > Bill Erickson
>> > | VP, Software Development & Integration
>> > | Equinox Software, Inc. / Your Library's Guide to Open Source
>> > | phone: 877-OPEN-ILS (673-6457)
>> > | email: erickson at esilibrary.com
>> > | web: http://esilibrary.com
>> >
>
>
>
> --
> Bill Erickson
> | VP, Software Development & Integration
> | Equinox Software, Inc. / Your Library's Guide to Open Source
> | phone: 877-OPEN-ILS (673-6457)
> | email: erickson at esilibrary.com
> | web: http://esilibrary.com
>