running RedNotebook journal 1.7.1 on XP and Win7

If you are trying to run the RedNotebook 1.7.1 journal / diary on a Windows desktop you may have hit the same problems which I have had to resolve on XP Sp3 and Win7 Home Premium with Sp1.

If your Win XP environment contains a PYTHONHOME variable then you must set it to something inocuous such as a dot for the current directory of the Rednotebook.

I am doing this with a call to X-RedNotebook.exe in a 3-line BAT file which I summon from a 2-line VBS script that has a shortcut on my desktop ( this keeps a daft black DOS shell window from hanging around.)

On Win7 Home Premium Sp1 I could not get 1.7.1 to run as the X-RedNotebook variant until I had dragged in copies of the DLL's of which it was complaining as missing.

If you need details, drop a note.

If your upgrade to 1.7.1 went without a hitch, I would love to know the secret !

---

The path to BFG: virtualenv bfgenv and _socket PYTHONHOME PYTHONPATH activate

The BFG python web framework folks pride themselves on their testing - but I can't say the same for virtualenv when installed under Windows.  And in this regard, the BFG web documentation is lacking (compared, say, to WebCore.)

First, the point of virtualenv is to be able to maintain a BFG server on a machine with python26 and python27 and python31  as we transition to python32 and beyond.  So they move a copy of some version of python.exe and pythonw.exe into a Scripts folder.  But they neglect to supply the respective python DLL. So copy that from your PYTHONHOME into that new bfgenv/Scripts directory.

The scripts will not work correctly if you do not first clean up your cmd environment by executing the following at that DOS shell prompt:

set PYTHONPATH=

but even then I have found that for my sanity I need to go into the new /bfgenv/Scripts and edit the activate.bat and deactivate.bat files to preserve and restore my %PYTHONPATH% as well %PYTHONHOME%

One symptom that there is a problem is having an install script complain about not finding a module which imports without problem in your 'normal' python environment.  In my case it was _socket

Sadly, I read advice on mail lists to reinstall Python.  "There must be something wrong with your Python install" as you will see by a web search on virtualenv _socket

Here is a set of steps which will work on Windows XP for Python 2.7 if \python27\Scripts is on your PATH

cd \python27

python ez_setup.py            (note: get this python script off the web for SetupTools)

easy_install virtualenv

set PYTHONPATH=

cd \

virtualenv --no-site-packages bfgenv

cd \bfgenv

Scripts\activate

Scripts\easy_install -i http://dist.repoze.org/bfg/current/simple repoze.bfg

cd Scripts

python test_bfg_port_28686.py   (note: this last is your test file - remember to choose a port)

Suppose PYTHONHOME had been conceived as a string such as

"27*c:\python27;31*i:\python312"

then this would not be an issue - so long as PYTHONPATH was not built by subst of %PYTHONHOME% or $PYTHONHOME

But that ship has sailed.

And take care when in \bfgenv to issue the command as

Scripts\activate.bat

because, like me, you may have more than one activate.bat in your path ... I mean, %PATH%.

Here is a 2009 blog post on using virtualenv: Chris Scott

The WebCore pages suggest using pip. And what could be simpler than

pip install CherryPy

PS
Of course, BFG on linux installed and ran like a charm ...
PPS
Check that %PYTHONHOME%\Scripts is on your PATH

configure & make node.js under Cygwin

Just one oddity with building node.js on cygwin (it was fine Ubuntu) and that is that I could not get ./configure to complete until it occurred to me to run

unset PYTHONHOME
unset PYTHONPATH

After that the

./configure
make
make install

ran without a hitch and node/js behaving much as it does on linux. 

The python module path issue was not becuase cygwin was using my Windows values: a simple bash check with
echo $PYTHONPATH
echo $PYTHONHOME
cleared that up.
The symptom could be seem by just running a verbose python REPL at thecommand prompt

python -v

and noting the "site" package error.  Yet loading sys and doing

print sys.path

showed no obvious problem.  I have seen this gift once when a linux version upgrade required a python version upgrade.  I checked in the registery under LOCAL_MACHINE | SOFTWARE but the three values there for python25, python26 and python31 look fine (although the latter appears truncated ...)

I tried various export statements and looked for a doubtful resource rc file or other config in /etc but the answer (porbably obvious enough) eludes me.

When set and export to reasonable values and to no value fail and there is nothing else odd reported by env then unset to the rescue.

Now back to looking at axiom and sproutcore as server-side JavaScript options.