VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Jul 27 2012 - 11:25:26 CDT

Olaf,
  I'm catching up on emails. As Axel has already pointed out,
you can already build VMD as a Python module, using the "SHARED"
configuration flag.

The main reason we do not integrate VMD as a Python module by default
is because that creates problems for VMD features that require VMD
be "in control" and be responsible for the main event loop.
Examples of these are:
  - MPI
  - Interactive MD
  - VR rendering with CAVELib, FreeVR, VR Juggler, etc.

Since all major target platforms now support multithreading, it is possible
to workaround some of the problems above in the case where Python would
control the main event loop, but it is not by any means "easy". The work
required to make both the VMD code and the other libraries listed above
thread-safe vs. the Python module interface would be quite complex and
very costly in terms of development time. That is time that would then
not get spent on developing new program features.

Compiling VMD itself as a Python module does not solve all the problems
I mentioned in previous emails, because those problems still affect any/all
python scripts that users write, such as IED, and compatibility with modules
that VMD is compiled against, such as NumPy / Numeric, etc. I do
agree that things are becoming more stable with Python going forward,
but it remains to be seen if there will be future compatibility problems
like the ones we've had to overcome in the past. I can only comment
on what we've had to deal with in the past and use that as rough
indication of where things might go in the future.

Cheers,
  John

On Wed, Jul 25, 2012 at 10:07:49AM +0200, Olaf Lenz wrote:
> Hi!
>
> On 07/24/2012 06:48 PM, John Stone wrote:
> >Going forward, I am hoping that we can choose to support just one
> >major version of Python and that we can start removing the remnants
> >of the oldest Python interface code in VMD to streamline future
> >efforts. If Python itself ends up being more stable in the next few
> >years, that would go a long way toward making it feasible to provide
> >a greater degree of integration in VMD than is currently provided.
>
> What I do not completely understand is why you chose to integrate the
> Python interpreter into VMD instead of making VMD a Python module. We
> have done this with our software ESPResSo, and we see various advantages:
>
> * It removes the versioning problem, as the API for Python extensions is
> pretty stable over various versions - in contrast to the interpreter API.
>
> * It would allow users to run VMD with the version of Python provided by
> their system.
>
> * It would allow users to use VMD in conjunction with any of the various
> other Python modules.
>
> BTW, the same goes for Tcl: one could also make VMD a package for Tcl,
> instead of integrating the interpreter into VMD. But I see that the
> effort is probably not well spent, as Tcl is mostly a dying language anyway.
>
> Olaf
>
> --
> Dr. rer. nat. Olaf Lenz
> Institut für Computerphysik, Pfaffenwaldring 27, D-70569 Stuttgart
> Phone: +49-711-685-63607
>
> 

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