From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Oct 26 2004 - 13:18:13 CDT

Warren,
  Nicely said. It would be a great thing if we could come up
with a common solution to this problem, since it definitely plagues
all of us developing tools that incorporate or otherwise depend on Python.

The average user doesn't ever want to mess with their system libraries,
doesn't even want to have to know that Python is being used for a particular
tool. I think in most cases they just want to see tools like "IED" show
up in an extensions menu and have them "just work". At the same time though,
we need to make our tools friendly to people that develop these tools, and
to allow for more sophisticated uses, and so I agree with some of
Konrad's points about not hamstringing him with a particular revision
of Python as well.

One of the other gotchas that often occurs with linking against
external libraries are the compilers, compiler linkage modes, and
other things that have to be consistent across the software package.
This is a particularly big issue with C++ in general, and also
specifically with Win32 linkage modes. The C++ issue is one of the
reasons I've historically had to statically link various libraries
into VMD. Even different revisions of GCC have at times been
incompatible with each other!!! :-)

I would love to see a method similar to the Tcl stubs mechanism for
linking python dynamically, and somewhat more version-independently.
Here's info on what Tcl does for this sort of thing:
  http://wiki.tcl.tk/285
  http://www.tcl.tk/man/tcl8.2.3/TclLib/InitStubs.htm
  http://www.tcl.tk/man/tcl8.2.3/TkLib/TkInitStubs.htm

  John

On Tue, Oct 26, 2004 at 10:25:52AM -0700, Warren DeLano wrote:
> 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
> > ---------------------------------------------------------------------
> >
> >
> >
>
>

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078