Updated patch looks good. Much obliged, Bill! -Mike
On Fri, Nov 5, 2010 at 11:24, Bill Erickson <erick...@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 > <leftw...@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 <erick...@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 >> > <leftw...@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 <d...@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: erick...@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: erick...@esilibrary.com > | web: http://esilibrary.com >