Embedding Python in Windows App , use of Registry & ENV to find modules

[qua...@primenet.com]

Hi,

I have embedded Python in a Windows App and am using it for a generalized
expression
evaluator and as a means to connect to other Apps via additional imported
Python modules.

The machines that this Windows App run on may or may not have full
installations of Python
on them at the time of installation of Windows App, or may have full
installation of Python applied
after installation of Windows App. In any case, I would like to safeguard
the Windows App from
Python version conflicts by isolating all required Python DLL's/EXE's/pyc's
etc.... into a location
I can control and keep separate from any other Python installations.

The only way I can see to do this practically, is to modify Py_Initialize()
and
PyWin_FindRegisteredModule() ( and possibly a few others ) to have
Environment variables and
Registry Keys of my own choosing. Recompile, relink etc...... and have the
install program create
said environment variables and Registry keys.

Does someone knowledgeable in such matters agree, or is there a better way?

Should I just go ahead and do a full install of Python on every machine
running the Windows App?

My fear is that some of these machines may already have Python on them and
some may get it
afterwards. Either way, myself or the other Python user may not appreciate
an unsolicited upgrade
( or downgrade ) to their Python installation. Notwithstanding potential
changes to Python itself
that could cause a problem if Windows App is written to expect some Python
version dependent
behavior........

I think I have located all required functions to be modified along with
identifying the necessary Registry
entries to be made.

Any thoughts or experiences with this sort of thing would be appreciated.

Thanks

qua...@primenet.com

[Dennis Reinhardt]

> Does someone knowledgeable in such matters agree, or is there a better
way?

I put python.exe and python22.dll in my own directory, have my own libstd
and libxtra directories below this. Python.exe is then called via explicit
path. One of the first statements before even doing imports is

sys.path = [".", ".\\bin", ".\\bin\\libstd", ".\\bin\\libxtra"]

to insure that the exact version I deliver is used and not whatever happens
to be installed. Also, see my web page
http://www.autorunning.com/arpyexe.cgi for a standalone demo embedding
Python noting especially that a working download is approx, 450 K.

I do *not* touch the registry or environment. IMO, this makes for a much
superior solution.

--
Dennis Reinhardt

http://www.dair.com

[Mark Hammond]

qua...@primenet.com wrote:
> The machines that this Windows App run on may or may not have full
> installations of Python
> on them at the time of installation of Windows App, or may have full
> installation of Python applied
> after installation of Windows App. In any case, I would like to
> safeguard the Windows App from
> Python version conflicts by isolating all required Python
> DLL's/EXE's/pyc's etc.... into a location
> I can control and keep separate from any other Python installations.

The simplest way may be to open the pre-built Python2x.dll in MSVC (as a
"resource", not as "auto", and change the single string resource from
the "2.x" it will be. This will then become sys.winver, and is used to
form the keyname Python used. You can change this to "foo", and have
Python look in HKLM\Software\Python\foo for all its settings. Thus,
your personal Python should not conflict with any others (assuming you
keep all Python files local to your application)

Or, as already suggested, just explicity set sys.path and/or PYTHONPATH
appropriately. The "Registered Module" concept is going away, and isn't
used by anyone I know of.

Mark.