Re: [Visualpython-users] History and Status?

[Bruce S. <bas...@un...>]

Note that the ideas are Scherer's -- I can't take any credit for them. But
it's a very good vision.

On the specific issue of distutils: It is probably correct that distutils is
exactly the right mechanism for all Linux/Unix-like environments, including
the new Mac OSX 10.2 X11 environment. But it seems a poor mechanism for
nonexpert users on Windows, who typically don't have a compiler available
(needed for source distribution) and are not comfortable working in a
command prompt window.

David Andersen once put together a distutils package for Linux, but
unfortunately I never followed up on deploying it. His script is shown
below. Suggestions are welcome on this; maybe it's ready to go?

Bruce Sherwood

-------------------------------------------------

After wasting a considerable amount of time thinking I had to parse the
includes and libraries my self, I finally realized the easy way to do it.

Here is a Unix/Linux setup.py:  Impressive that it takes so little code.

#!/usr/bin/env python
# To use:
#       python setup.py install
#
import sys
if not hasattr(sys, 'version_info') or sys.version_info < (2,0,0,'alpha',0):
    raise SystemExit, "Python 2.0 or later required to build VPython."
import distutils
from distutils.core import setup, Extension
from os import popen3

w,r,e = popen3("gtk-config --cflags gtk gthread")
gtkconfig = r.read()
err = e.read()
if (err):
    raise ValueErr("Unexpected %s on gtk-config stderr",`err`)
extra_compile_args = gtkconfig.split()

w,r,e = popen3("gtk-config --libs gtk gthread")
gtkconfig = r.read()
err = e.read()
if (err):
    raise ValueErr("Unexpected %s on gtk-config stderr",`err`)
extra_link_args = gtkconfig.split()

setup (name = "cvisual",
  include_dirs = ["CXX/Include"],
         ext_modules = [Extension('cvisualmodule',
['cvisual.cpp',
'CXX/Src/cxx_extensions.cxx',
'CXX/Src/cxxextensions.c',
'CXX/Src/cxxsupport.cxx',
'arrow.cpp',
'arrprim.cpp',
'box.cpp',
'color.cpp',
'cone.cpp',
'convex.cpp',
'curve.cpp',
'cylinder.cpp',
'display.cpp',
'displaylist.cpp',
'faceset.cpp',
'frame.cpp',
'gldevice.cpp',
'kbobject.cpp',
'label.cpp',
'light.cpp',
'mouseobject.cpp',
'platlinux.cpp',
'prim.cpp',
'pvector.cpp',
'rate.cpp',
'ring.cpp',
'sphere.cpp',
'tmatrix.cpp',
'vcache.cpp',
'xgl.cpp'],
    extra_compile_args = extra_compile_args,
    extra_link_args = extra_link_args,
    libraries = ["GL","gtkgl"])
                     ]
       )

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Bruce Sherwood" <bas...@un...>; "John Keck"
<joh...@ho...>; <vis...@li...>
Sent: Sunday, February 16, 2003 5:27 PM
Subject: Re: [Visualpython-users] History and Status?


> Bruce writes:
>
> > Design Goals:
> >
> > 1.  Preserve at least the current level of usability and performance
> > 2.  Make VPython easier to maintain
> > 3.  Make VPython easier to extend.  There should be a gentle path
> > between user and implementor, not a gaping chasm.
> > 4.  Make VPython more useful and less limiting for experts, so as to
> > increase the availability of expert help to the VPython community.
> > 5.  Make VPython play nicer with other Python packages and tools
>
> Well thought out.
>
> As to point 5, I am quite convinced that a step toward that goal is the
use
> of Python's distutils as the basis for the distribution mechanism. I can
be
> and would be willing to be helpful here - as I have gotten hands on with
it,
> and find it friendly and flexible.
>
> As I have said many times, I think VPython has some unique qualities.
Which
> if built upon along the lines you suggest, will, I believe allow it be an
> enduring and even more significant project.
>
> But as you suggest, it would need to atttract some developers to get it
over
> the hump to a next phase.
>
> I, for one, am willing to spend time on it.  The problem being I am more
of
> a Python person than a C++, or C guy. But I am willing to approach the
> learning curve, especially if there are brains around to pick.  I do come
to
> it with a decent grasp of OpenGL. Though I would need to get up on some of
> the newer version features.  That being VPython's fault - as I was doing
> more directly in PyOpenGL before VPython came along, with much of what I
was
> trying to do - prebuilt.
>
> I am even willing to try to do some recruiting for the project- perhaps at
> the PyCon event in DC next month.
>
> How do we work toward establishing some concrete ideas for bringing more
of
> your thought experiment to life.
>
> Art
>
>
>