[OPEN-ILS-DEV] OpenSRF 101
Bill Erickson
erickson at esilibrary.com
Fri Nov 5 11:24:59 EDT 2010
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20101105/ee688a3f/attachment.htm
More information about the Open-ils-dev
mailing list