[Python-Dev] DLL in the system directory on Windows.

[Guido van Rossum]

[me]
> > One more thing that I just realized.  There are a few Python extension
> > modules (_tkinter and the new pyexpat) that rely on external DLLs:
> > _tkinter.pyd needs tcl83.dll and tk83.dll, and pyexpat.pyd needs
> > xmlparse.dll and xmltok.dll.

[Jim A]
> Welcome to the club.

I'm not sure what you mean by this?

> > If I understand correctly how the path rules work, these have to be on
> > PATH too (although the pyd files don't have to be).  This worries me
> > -- these aren't official MS DLLs and neither are the our own, so we
> > could easily stomp on some other app's version of the same...
> > (The tcl folks don't change their filename when the 3rd version digit
> > changes, e.g. 8.3.0 -> 8.3.1, and expat has no versions at all.)
> > 
> > Is there a better solution?
> 
> This is a daily annoyance and risk in the Windows world.  If you require
> Tk, then you need to completely understand how to produce a valid Tk
> distribution.  Same with PIL (which requires Tk).  Often you won't
> know that some pyd requires some other obscure DLL.  To really do this
> you need something high level.  Like rpm's on linux.  On Windows, people
> either write complex install programs with Wise et al, or run third
> party installers provided with (for example) Tk from simpler install
> scripts.  It is then up to the Tk people to know how to install it, and
> how to deal with version upgrades.

Calculating the set of required DLLs isn't the problem.  I have a tool
(Dependency Viewer) that shows me exactly the dependencies (it
recurses down any DLLs it finds and shows their dependencies too,
using the nice MFC tree widget).

The problem is where should I install these extra DLLs.

In 1.5.2 I included a full Tcl/Tk installer (the unadorned installer
from Scriptics).  The feedback over the past year showed that this was
a bad idea: it stomped over existing Tcl/Tk installations, new Tcl/Tk
installations stomped over it, people chose to install Tcl/Tk on a
different volume than Python, etc.

In 1.6, I am copying the necessary files from the Tcl/Tk installation
into the Python directory.  This actually installs fewer files than
the full Tcl/Tk installation (but you don't get the Tcl/Tk docs).  It
gives me complete control over which Tcl/Tk version I use without
affecting other Tcl/Tk installations that might exist.  This is how
professional software installations deal with inclusions.

However the COM DLL issue might cause problems: if the Python
directory is not in the search path because we're invoked via COM,
there are only two places where the Tcl/Tk DLLs can be put so they
will be found: in the system directory or somewhere along PATH.

Assuming it is still evil to modify PATH, we would end up with Tcl/Tk
in the system directory, where it could once again interfere with (or
be interfered by) other Tcl/Tk installations!

Someone suggested that COM should not use Tcl/Tk, and then the Tcl/Tk
DLLs can live in the Python tree.  I'm not so sure -- I can at least
*imagine* that someone would use Tcl/Tk to give their COM object a bit
of a GUI.  Moreover, this argument doesn't work for pyexpat -- COM
apps are definitely going to expect to be able to use pyexpat!

It's annoying.

I have noticed, however, that you can use os.putenv() (or assignment
to os.environ[...]) to change the PATH environment variable.  The
FixTk.py script in Python 1.5.2 used this -- it looked in a few places
for signs of a Tcl/Tk installation, and then adjusted PATH to include
the proper directory before trying to import _tkinter.  Maybe there's
a solution here?  The Python DLL could be the only thing in the system
directory, and from the registry it could know where the Python
directory was.  It could then prepend this directory to PATH.  This is
not so evil as mucking with PATH at install time, I think, since it is
only done when Python16.dll is actually loaded.

Would this always work?  (Windows 95, 98, NT, 2000?)  Wouldn't it run
out of environment space?  Wouldn't it break other COM apps?  Is the
PATH truly separate per process?

--Guido van Rossum (home page: http://www.python.org/~guido/)