lupo__ (lupo@pD9542922.dip.t-dialin.net) joined #gnuenterprise. wendall911 (~wendallc@198.31.172.218) left irc: "Download Gaim [http://gaim.sourceforge.net/]" reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) joined #gnuenterprise. siesel (jan@xdsl-213-196-192-160.netcologne.de) joined #gnuenterprise. morning hi reinhard, hi Sascha. The webfrontend just works with the old pw_xmlrpc driver at the moment After the rpc change, it can be selected with xmlrpc.pw_xmlrpc (I think) If there still regressions, ... I will read the log. brb reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) left irc: "Don't believe in miracles -- rely on them." b(not so)rb siesel (jan@xdsl-213-196-192-160.netcologne.de) left irc: "Leaving" reinhard (~reinhard@M1264P004.adsl.highway.telekom.at) joined #gnuenterprise. thierry (~thierry@musashi.xtensive.com) joined #gnuenterprise. hi all hi good morning all brb trying to get defoma to work right dneighbo_ (~dneighbo@ip68-109-180-32.ph.ph.cox.net) left irc: "Bye Bye" derek (~dneighbo@ip68-109-180-32.ph.ph.cox.net) joined #gnuenterprise. dcmwai (~dcmwai@219.95.164.179) joined #gnuenterprise. btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. hello hi btami hi reinhard Arturas (~arturas@gsk.vtu.lt) joined #gnuenterprise. Hello thierry_ (~thierry@musashi.xtensive.com) joined #gnuenterprise. thierry (~thierry@musashi.xtensive.com) left irc: Read error: 110 (Connection timed out) Nick change: thierry_ -> thierry re thierry (~thierry@musashi.xtensive.com) left irc: "Client exiting" thierry (~thierry@musashi.xtensive.com) joined #gnuenterprise. Nick change: SachaS -> SachaDinner dcmwai (~dcmwai@219.95.164.179) left irc: "Client exiting" dimas (~dimas@195.218.177.46) left irc: Read error: 60 (Operation timed out) Nick change: SachaDinner -> SachaS btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: Read error: 110 (Connection timed out) btami (~tamas@ip102-205.ktv.tiszanet.hu) joined #gnuenterprise. ToyMan (~stuq@smtp.dstoys.com) joined #gnuenterprise. stuq_ (~stuq@smtp.dstoys.com) joined #gnuenterprise. stuq_ (~stuq@smtp.dstoys.com) left irc: Remote closed the connection lupo__ (lupo@pD9542922.dip.t-dialin.net) left irc: "using sirc version 2.211+KSIRC/1.1" dimas (~dimas@195.218.177.46) joined #gnuenterprise. btami (~tamas@ip102-205.ktv.tiszanet.hu) left irc: "going home" jamest (~jamest@gw.math.ksu.edu) joined #gnuenterprise. hi jamest afternoon jamest hi dsmith (~dsmith@mail.actron.com) joined #gnuenterprise. tripz_ (~ville@as13-5-6.ld.bonet.se) left irc: "using sirc version 2.211+KSIRC/1.2.4" jcater (~jcater@cpe-066-061-071-147.midsouth.rr.com) left irc: "Client exiting" jamest: I have committed a setup.py and a setup-cvs.py that creates a "paths" module that is once you have pythonpath set correctly you can simply do from gnue import paths print paths.libs print paths.data print paths.scripts print paths.config (<- not working yet) doing it this way looks quite easy and straightforward to me so i'm not sure why it wasn't done like this and i'm not sure if i overlooked something so please give me your feedback if i should continue this path or not i can't look now but if this means that I can use gnue-commong without all the bullshit I normally go thru the please continue can you precise "bullshit"? sure, hang on # # Setup the environment to know where gnue is installed # import sys,os,string sys.path.append('/usr/local/gnue/lib/python') os.environ['INSTALL_LIB']='/usr/local/gnue/lib/python' os.environ['INSTALL_PREFIX']='/usr/local/gnue' # GNUe modules from gnue.common.apps.GClientApp import * from gnue.common.apps import GDebug from gnue.common.utils.TextUtils import lineWrap from gnue.common.formatting import GTypecast i have to do the top part before I can start from gnue.blah import foo part and I wanted that to go away well that would be changed to either import sys both jcater and I looked into this seperately and couldn't come up w/ something simpler sys.path.append ('/usr/local/gnue/lib/python') if gnue isn't installed in python search path or # nothing to do here if gnue is installed in site-packages but the environment variables would go away as a result of this what I wanted to do was import gnuesys that did all the stuff above automatically ah ok or something similar so gnuesys sets the os.path yeah and is _always_ installed in gnues search path gnuesys is always install in pythons default search path regardless of where gnue itself is installed that was the kicker for us what i don't understand is if we install something in site-packages anyway why don't we simply install gnue as a whole there again, i don't recall why we did what we did too many years have gone by :) to install something in pythons search path might require root access to the machine and if we don't somebody could install gnue into his home dir and add PYTHONPATH=~/gnue to his .profile maybe that was it, i really don't recall why we did it i do recall the whole scripts wrapper thing was done to support it and I think we're all lazy enough to have NOT done it without at least some reason :) except for that austrian dude he's a commiting machine lately tripz_ (~ville@as13-5-6.ld.bonet.se) joined #gnuenterprise. however doesn't you new setup's make most this go away? that the system does now install in site-packages? or is the default still /usr/local/gnue and do you think it'd be possible to optionally install some type of "import gnuesys" support if the installation location isn't in the default searchpath? that would be possible i thought about that, too although the default python search path has several parts so the user should be able to select where he wants that installed isn't python standard /usr/lib/python-#.#/site-packages depends on the platform... >>> sys.path ['', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload', '/usr/local/lib/python2.1/site-packages', '/usr/lib/python2.1/site-packages', '/usr/lib/site-python'] is the default for debian R45 (~rastabeen@cuscon326.tstt.net.tt) joined #gnuenterprise. ok.. I have a gpl question jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. jcater: if you have time please read today's logs hmm we have a php application.. does using a GPL'd module, a library to create menus for instance, force the whole application under the GPL? am I fired? lol (to jcater) no, boss :) I'm becoming more and more indifferent to how it's handled each day I still do see some issues w/installing in site-packages but none that I'll argue deeply about if we put in site-packages, we may need to rethink our packaging strategy on debian as then shouldn't we have gnue-forms, gnue-data, python2.1-gnue, python2.2-gnue, et al well i think we have 3 options (that's not an argument against, btw... just a question) 1) install everything under site-packages what was that /usr/lib/site-python ? 2) install wherever we want and have some gnuesys in site-packages that contains only sys.path.append 3) install wherever we want and stay keep our wrapper scripts s/stay// for 3) we will need python2.1-gnue and for 2) we will even need python2.1-gnue, python2.1-gnue-forms etc. no crap I like 2, I think but I disagree with and for 2) we will even need python2.1-gnue, python2.1-gnue-forms etc. I think we'd just need python2.1-gnue python2.2-gnue for 2) we will need python2.1-gnue that all it did was install the gnue-sys for 1) we will need python2.1-gnue arrgh. stop it sorry now correct :) for 2) we will need python2.1-gnue and for 1) we will even need python2.1-gnue, python2.1-gnue-forms etc. ok now so :) jcater: 1) and 2) will break multiple installs on same machine well 1 would break multiple installs 2 might 2 would only break the gnuesys stuff, and external programs that depend on it but not gnue programs i.e., it'd screw w/jamest's custom programs jcater: with 2 you might prbably not be able to have cvs version of say, forms running on same machine as you have a version of forms installed hmm true and if we look at 3) (wrapper scripts) it would be quite straightforward if we reduce the wrapper to a simple sys.path.append what i didn't like so much was the evironment variables that did get set _somewhere_ and influenced _something_ like I'm not sure 2 and 3 are mutually exclusive INSTALL_LIB, INSTALL_PREFIX, INSTALLED_GNUE_CONNECTIONS, GNUE_CONNECTIONS etc. yeah jcater: i'm sure they are _not_ mutually exclusive I don't particularly care for all the environ variables either even though I think I implemented them that was > 2 years ago ... I can change my position in that amount of time, right? :) but what good would it be to implement gnuesys in site-packages if we don't get rid of the wrapper scripts anyway well you'd have to have some sort of wrapper script, right? even if it's 1-2 lines as we wouldn't expect the user to run: python2.1 gnue.forms.GFClient myform.gfd sorry i was unclear i mean _generated_ wrapper script _installtime_generated_ wrapper script well ooo I just saw this statement but what good would it be to implement gnuesys in site-packages if we don't get rid of the wrapper scripts anyway Action: jcater is slow we were originally wanting gnuesys to our custom apps could use GNUe's library internally which if it can get rid of stuff in wrapper scripts, that's good to but just to clear up the original intention we had Action: jcater is thinking, hang on a second we'll always have to have installtime-generated wrapper scripts simply because if nothing else, we need to know which python binary to use Action: jcater just thought of that well on _normal_ installs we would simply have "python" are you sure? if we have the python version in the wrapper scripts, we have python2.1-forms, python2.1-reports etc. I'm reasonably sure we should use whatever was used to run setup.py yes in a normal install "python" would be used to run setup.py :) which for debian files, would be "python" yes :) hmm well if we make these shells "py" scripts instead of "shell" scripts distutils would change that top line automatically they are py scripts so if our gnue-forms is: ah we've changed it ? not sure what it was before but now they are python scripts all starting with /bin/env python and FWIW distutils _doesn't_ change the top line hmm they changed it? not sure however it is good IMHO because otherwise our wrapper scripts wouldn't work if we upgraded from python2.1 to python2.2 we somehow must decide on whether we want to be python version independent or not if we want to be independent, the python version may not be in the wrapper scripts, either if we want to be dependent, we can install in site-packages anyway I'd prefer to be independent I think would you be positive that gnue works with python2.4? no then it might be risky to make it independent well only when you make it always use the default python the disadvantage to making it solely dependent is if I do upgrade from 2.1 to 2.3 on a particular machine everything must be upgraded from my gnue installation to all my custom scripts whihc may not be that big a deal what do you mean with "custom scripts"? non-gnue .py files that use common? yes ah ok i understand i have lots and lots of them that's why I wanted that import gnuesys thing god, is there no good bug tracking software, that is simple and easy to install? jamest: what you want is to put in every custom script the line impurt gnuesys before every other line import even ;) yes if we had import sys sys.path.append ("/usr/local/gnue/lib/python") and it's done with that would that still be ok, or would import gnuesys be better? and other question ideally it'd be import gnuesys if you have lots of hand-made scripts then if my gnue install changes locations my scripts don't have to be updated (which are site specific anyway i guess) you could also manually do a gnuesys.py yip i could please don't get me wrong it's a minor complaint on my end just a wishlist item that it would be if common did it for me well what I would like to see i just don't see what the average user wanting to install just gnue because he wants just gnue is gnue in a custom location would gain from gnuesys reinhard: nothing, I imagine but it'd be nice to have a python2.1-gnue, python2.2-gnue, etc that all it did was setup a gnuesys file gnue-common is a nice lib to use outside of gnue at least for me and python2.x-* type files are usually for knowledgable people anyway so jamest could install python2.2-gnue import gnuesys and if he upgrades to python2.3, then python2.3-gnue would write a new gnuesys and his scripts still work just like they did that's how I envisioned gnuesys and of course the python2.2-gnue .deb would depend on gnue-common.deb Action: jcater is just thinking out loud here the disadvantage to this approach is the gnue-forms script would have to have a sys.path.insert(0,'.....') no gnue-forms could depend on python-gnue and python-gnue would be provided by any of python?.?-gnue that is true too and the forms script would just do import gnuesys although _that_ would break multiple installs well, no if I want a multiple install if we _want_ multiple installs I can very easily do gnue-forms4: #!/bin/sh export PYTHONPATH=/path/to/old/gnuesys python /path/to/old/gnue-forms will that be taken _before_ the standard path? yes good I'm positive your custom PYTHONPATH's can override installed packages so as a sysadmin, I'd have to create a script but I could still fairly easily do multiple installs it wouldn't be fully automated but I don't think that matters no i don't think either apart from that, cvs scripts (like gfcvs) wouldn't import gnuesys anyway so you could _always_ have a cvs repository parallel to an installed version which is the most likely case anyway IMHO so if we stick to that, we might even ditch the gnue-$script.in stuff and make static scripts again and all of them simply would contain import gnuesys is that the way we want to go? I think it's worth trying the worst case is it doesn't work for us so 2 years from now, we change our minds again :) lol lol good good ... luck ;) btw, do we want to call it gnuesys? is that the decided name? no IIRC jamest always called it like that i don't have an idea on how to call it btw I have a trick with sys.modules where you could literally call it gnue.py so you could do from your script import gnue.common the "gnue" part of that import would load the gnue.py but the gnue.py replaces sys.modules['gnue'] with the real gnue.* tree gnuesys was only off top of head so it is a seemless import that would be ideal IMHO just found out there's no way to find out the name of the site-packages dir platform independently wendall911 (~wendallc@198.31.172.218) joined #gnuenterprise. :( what do you need that for? well in setup.py i need to know where to create gnuesys.py (or gnue.py) :( jcater: how would i replace sys.modules['gnue'] with the real gnue tree? sys.modules['gnue'] = "/path/to/gnue" doesn't work hang on... reinhard: I know you're busy, but do you have time for a couple questions? let me test something, but I think it involves updating your path then "reloading" gnue ok import sys sys.path.insert(0,'test') del sys.modules['gnue'] import gnue that is gnue.py I have to run to lunch jcater: this is the work of a genius we'll do it exactly like this don't you just love what python's dict based structure makes possible :) wendall911: yes, in 15 minutes reinhard: cool currently i'm putting kids to bed and so i'm in and out btw sysutils is great eh distutils >>> from distutils import sysconfig >>> sysconfig.get_python_lib () '/usr/lib/python2.1/site-packages' wendall911: ready wendall911: i have time now Nick change: SachaS -> SachaZzz Arturas (~arturas@gsk.vtu.lt) left irc: "Bye :)" reinhard: sorry, was afk for a few reinhard: I have a company that was using Metastorm ework and that fell flat on its face. I've written a proposal for using GNUe with all the possible arguments against using another proprietary solution. When I get asked if this is "enterprise level" what do you think would be my best response? chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) left irc: Remote closed the connection wendall911: i'm not a native english speaker and i'm not sure i understand the word "enterprise level" exactly enough to answer the question reinhard: I was thinking during lunch about that code I gave you reinhard: How well can it scale to use with large numbers of companies? and it works great, until gnue.py exists w/o a gnue.* directory somewhere I can't imagine why that would happen but for the sake of doing robust code we should change that to: import sys origpath = sys.path sys.path = ['/path/to/gnue'] del sys.modules['gnue'] import gnue sys.path = origpath .. otherwise, it would go into an infinite import loop this way, it would raise an ImportError jcater: i understand wendall911: we have no experience with that at all our _target_ is that it scales well however we have no idea about whether we are there or not reinhard: I am sure GNUe will, I'm telling them a couple years of development for a system that will work at that level. Fair enough? and lots of donuts, you forgot to mention the donuts. mmmm Action: jcater drools but not the vegan kind I need my daily fat intake wendall911: yes, i could sign that mouns (mouns@kali.mouns.org) joined #gnuenterprise. thierry (~thierry@musashi.xtensive.com) left irc: Read error: 60 (Operation timed out) chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) joined #gnuenterprise. wendall911 (~wendallc@198.31.172.218) left irc: Remote closed the connection Vee (~vin@cavok154.august.net) left irc: Read error: 104 (Connection reset by peer) Vee (~vin@cavok154.august.net) joined #gnuenterprise. siesel (~jan@xdsl-213-168-118-177.netcologne.de) joined #gnuenterprise. jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) left irc: Remote closed the connection tamas (~btami@ngprs.pannongsm.hu) joined #gnuenterprise. jcater (~jason@w202.z065105010.mem-tn.dsl.cnc.net) joined #gnuenterprise. siesel: there is no "gnue.common.rpc.drivers._directory" exist yet, but it's in common's setup.py jamest: sorry it seems the origpath thing won't work del sys.modules["gnue"] seems to destroy all local variables err jcater not jamest oh oh well the case I was protecting against shouldn't happen unless someone really, really botched their install :) Nick change: tamas -> btami R45 (~rastabeen@cuscon326.tstt.net.tt) left irc: ToyMan (~stuq@smtp.dstoys.com) left irc: "Client Exiting" btami: sorry, I forgot to remove it after the rpc update. ok