Just to close this thread, I thought I should post the final copies of
my scripts that solved my python version conflict - thanks to the help
of Thomas and Derrell. You guys are absolutely lifesavers when it comes
to Qooxdoo users!
To summarize the python situation, I have Python 2.3.4 installed with
executable programs in the /usr/bin folder named "python" and
"python2.3" (identical file just duplicated by the OS installation I
presume). I also have a link to the "python" executable file named
"python2" that the OS must use in some system scripts. When I installed
Python 2.4 on my system to use with Qooxdoo, it created the executable
program in /usr/bin named "python2.4" for running the newer python
version.
Now for the solution:
First, I verified that /usr/local/bin already appeared early enough in
my path variable (ahead of /usr/bin) that I didn't need to do any path
modifications for my solution - YMMV. You might choose a different path
on your system if this path is not before the path for the python
program files - you'll need to verify where your system has the python
executable files, as this might vary by Linux distribution. Since
my /usr/local/bin already appeared ahead of the /usr/bin, where the
python executables reside, I just created the following two scripts
in /usr/local/bin and marked them both as executable.
First, I created a bash script named ".bashrc.qooxdoo" to set my Qooxdoo
environment variables whenever I want to enable the use of python 2.4
over the default system python 2.3.4...
#!/bin/sh
QOOXDOO=true
export QOOXDOO
alias python=python2.4
alias create=/opt/qooxdoo.trunk/tool/bin/create-application.py
I can call this script after opening a new terminal prompt for working
in Qooxdoo by issuing the following command (remember,
the /usr/local/bin folder is in my path, so I don't need any path
prefixes):
. .bashrc.qooxdoo
Next, I created the script named "python" as instructed by Derrell...
#!/bin/sh
if [ ${QOOXDOO} ]; then
exec /usr/bin/python2.4 $*
else
exec /usr/bin/python $*
fi
Since this path appears before /usr/bin in my path variable, issuing the
"python" command anywhere in my system causes this script to be run
INSTEAD of the python executable file itself, and it runs the correct
python version directly. Now, when the Qooxdoo toolchain issues an exec
commands to python in that terminal window, this script runs the correct
python version for the toolchain as long as I've set the environment
through the first script. Please note that any other system terminal
window or system processes that use python should correctly call the
native python version through this script because the QOOXDOO variable
is only set in my active terminal window for working on Qooxdoo.
For the rare instance where I want to use the terminal window for the
native python 2.3.4, I created an additional script program named
".bashrc.resetqooxdoo" to reset the QOOXDOO variable and alias
settings...
#!/bin/sh
unset QOOXDOO
export QOOXDOO
unalias python
unalias create
This effectively solved the python version conflict on my system,
allowing me to use the Qooxdoo toolchain without any script
modifications for the special python version. I suspect this will work
regardless of whether the system python is newer or older than the
python installed for use by Qooxdoo, so future Linux versions that
install Python 3 as the default will require Qooxdoo users to install a
Python 2.x version for Qooxdoo and implement a similar patch to run the
earlier Python version in their Qooxdoo development work.
Thanks again for all your help, guys.
Gene Amtower
PC Backup
On Sun, 2009-05-24 at 08:21 -0400, Gene Amtower wrote:
> Thomas and Derrell,
>
> This worked like a charm!
>
> I also created an alias for "create" that runs the create-
> application.py script with the full pathname to the tool/bin folder so
> that I don't have to enter the entire path myself to create a new
> project.
>
> Ah, life just got so much better!
>
> BTW, this may become a problem again once Linux distributions start
> shipping with the new python 3.0 version rather than a 2.x version -
> unless the toolchain for qooxdoo gets rewritten in python 3.0.
>
> Many Thanks,
>
> Gene
>
> On Sun, 2009-05-24 at 11:40 +0200, thron7 wrote:
>
> > Gene,
> >
> > I apologize, but I was not thinking of the fact that aliases are not
> > passed down to subshells. So Derrell's approach is perfect, since it takes
> > advantage of environment variables (like PATH) which do get passed.
> >
> > > I do appreciate your insight into the issue - I can't be the only guy
> > > with a system Python version that conflicts with my newer Python for
> > > Qooxdoo, can I?
> >
> > We had similar issues way back when MacOSX shipped with a 2.3 version of
> > Python. I currently juggle three Python installations on my Linux box
> > (2.5.0, 2.5.1, 2.6.1), where I have two installations in separate paths,
> > and two side-by-side (and two of them with the Stackless patch). So I do
> > switch between them once in a while, but mostly in only a half-conscious
> > manner, where I bang on shell settings and proxy scripts until everything
> > works the way I want it... oh, well. Actually, I think you can even use a
> > soft link from an early PATH element to the Python executable (like
> > ~/bin/python -> /usr/bin/python2.4), to force a specific version from the
> > generic name.
> >
> > Thomas
> >
>
>
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
