From: Warren DeLano (warren_at_delanoscientific.com)
Date: Tue Oct 26 2004 - 12:25:52 CDT

Konrad,

While I agree that those of us who make use of Python as an integral part of
our software need to get our act together when it comes to guaranteeing
interoperability between our programs (and PyMOL is certain no exception to
this), there is another side of the picture, since there are many thousands
of PyMOL and VMD users who don't care about Python and don't want to be
troubled with Python installation, versioning, and sys.path-configuration
issues. John and I both put in significant work to insure that the
precompiled executable we ship will work in *most* cases on each platform,
in heterogenous environments, with or without Python of any vesion, and even
for the most naïve users. Even the Mac situation isn't quite as clean as you
suggest since there are really two camps: those that use Python in an
X11-dependent (with an X11-build of Tkinter), and those who do not.

Regardless, I do think that all of us (Konrad, John, Michel Sanner, the
Chimera team, the PHENIX team, the CCP4mg team, myself, and others) should
come to a meeting of minds with respect to how we are going to support
Python-based interporability on each platform. That would imply a standard
Python build and an agreed set of conventions for linking to it. It could
the system Python on 10.3+ based macs, but the situation is less well
defined on Windows and Linux.

Two of the key problems with viewing Python "as an integral part of a
computer system" is that (1) root access is usually required for
installation and (2) it then becomes nearly impossible to support multiple
simultaneous versions of interdependent components. I personally believe
that unprivileged, user-space Python installs have significant advantages.

Cheers,
Warren

--
mailto:warren_at_delsci.com
Warren L. DeLano, Ph.D.
Principal Scientist
DeLano Scientific LLC
400 Oyster Pt. Blvd., Ste 213
South San Francisco, CA 94080
(650)-346-1154  Fax:(650)-593-4020
  
> -----Original Message-----
> From: owner-vmd-l_at_ks.uiuc.edu 
> [mailto:owner-vmd-l_at_ks.uiuc.edu] On Behalf Of hinsen_at_llb.saclay.cea.fr
> Sent: Tuesday, October 26, 2004 9:07 AM
> To: John Stone
> Cc: vmd-l_at_ks.uiuc.edu
> Subject: Re: vmd-l: python2.3 and vmd
> 
> On Oct 25, 2004, at 20:37, John Stone wrote:
> 
> > Another option that appeals to me is to just include the python 
> > library that VMD is compiled against in the binary 
> distribution.  This 
> > would eliminate the necessity for the average user to have to mess 
> > with
> 
> The question is: why do people use Python within VMD? If most 
> users just want to script VMD and happen to prefer Python to 
> Tcl, that approach would help. If, on the other hand, most 
> users are Python programmers who see VMD as "yet another 
> Python module", then they wouldn't be interested: they would 
> most certainly want to use the copy of Python they already 
> have fine-tuned for their needs with added modules.
> 
> I am not going to hide the fact that I am in the second category.
> 
> > problem at present.  As far as I know, Python does not provide an 
> > equivalent of Tcl's "tcl stubs" functionality, so there's 
> basically no 
> > way to strongly insulate VMD against Python version changes and 
> > incompatbilities.
> 
> No. Compatibility is pretty good over many generations of 
> Python, but at the source code level. C modules need to be 
> recompiled with every change in the second digit of the 
> version number.
> 
> I see Python as an integral part of a computer system. It is 
> there, and everything that needs it builds on the existing 
> interpreter. That way all modules can be freely used 
> together, which is what makes Python so powerful. Linux and 
> MacOS (since 10.3) follow that approach: they come with 
> Python preinstalled and nobody other then Python developers 
> and testers would ever install another copy.
> 
> > What would be ideal would be to implement text interpreters 
> in VMD as 
> > plugins that are completely dynamically linked.  There are numerous
> 
> Either that, or have interpreters in separate processes that 
> communicate over sockets.
> 
> Konrad.
> --
> ---------------------------------------------------------------------
> Konrad Hinsen
> Laboratoire Léon Brillouin, CEA Saclay,
> 91191 Gif-sur-Yvette Cedex, France
> Tel.: +33-1 69 08 79 25
> Fax: +33-1 69 08 82 61
> E-Mail: hinsen_at_llb.saclay.cea.fr
> ---------------------------------------------------------------------
> 
> 
>