On Feb 21, 8:06 pm, [EMAIL PROTECTED] wrote: > I don't know the specifics of your app, but why does everyone insist > that they need to use the 'system' python?
Hey Grant, don't worry it's not a rant. A completely valid question. Again it's a problem of dependency management ... one of the things we've had to deal with is one of the applications : they have a framework largely built in python, and I think they were indeed at one point shipping their own python because they used features not present in the "system" python. However, they did use the middleware installed on the system, and this middleware is also partially written in python ... except it was expecting the system python. So you get into very tricky things having to sanity check the PYTHONPATH, that the "user" python path is not getting exported into middleware land, nor is the application's desired PYTHONPATH being destroyed by middleware. We had just such an issue here last week, we had solved the problem for bourne shell users, but csh for some reason had a different behavior, and the user app could not longer find its python modules. About the only code for which we don't seem to have these issues is compiled C. C++ is nasty because the compilers are still catching up to the standard; the last I heard, a big segment of C++ code was stuck because it was full of apparently illegal constructs that the previous compiler (the g++ shipped stock with RHEL3) accepted, but the RHEL-4 native version refused to compile. A colleague of mine pointed out today that this is an old problem, and used to be handled by automake at compile time, with code full of ifdefs ... now we've moved the problem to run time. Which I think is harder, because sometimes we don't find the problem until our binary is halfway across the world ... JT -- http://mail.python.org/mailman/listinfo/python-list