visualpython-users

Re: [Visualpython-users] History and Status?

[Jonathan B. <jbr...@ea...>]

On Tue, 2003-02-18 at 16:34, Arthur wrote:
> It terms of concrete effort, I will be pursuing the extension to the
> setup.py for VPython I did, so that it will be workable with Linux. Other
> than my own learning curve to refamiliarize myself with certain Linux
> issues, should not be a big deal.  As Bruce notes, the actual Linux setup.py
> is essentially  already there - its really just a matter of testing for
> platform and branching appropriately.
> 
> Should be able to get it to be basically functional, with the place of docs,
> demso somewhere - as a draft - pending more discussion.
> 
> But the iterator thingy (technical term) issue is on my mind.
> 
> I am working with a recent Linux install, therefore gcc3.xx.
> 
> Am I correct in assuming that the fix to the CXX file needed to compile on
> gcc > 3 does not break anything if compiling under a gcc < 3.  Which would
> raise the question why it was there at all.  There is probably a way to test
> for gcc version and fork accordingly, but I don't know if its necessary.

Unfortunately, No.  Most GCC < 3 are broken by the current setup. 
Namely the stock versions distributed with RH7 and Debian woody (at the
minimum).  It's not as simple as testing for __GNUC__ < 3, because at
least one of the 2.95 builds supported only the ISO version, and would
subsequently fail.  Most G++ 3.x distributions' verson of libstdc++
support both the old random_access_iterator<> and newer iterator<>.  The
problem is that Apple distributes their G++ with a C++ standard library
that is not backwards compatable in this respect.

In the Great ISO Migration, some older distributions are only partially
in compliance.  Most current distributions are fully compliant or nearly
so, and are also backwards-compatable (stock g++3.2.x with corrisponding
libstdc++).  A handful of current distributions are fully or nearly
fully ISO compliant and are NOT backwards compatable (Apple special
distro).  Ironically, the last group is the one causing causing us the
trouble.

Is it possible to run a shell command from within setup.py, and capture
the return value to set a CXXFLAG?  If so, then a solution could look
like this:

Provide a file named iterator_traits_test.cpp:
--------iterator_traits_test.cpp--------------
#include <iterator>

std::iterator< std::random_access_iterator_tag, int, int> test;

----------------------------------------------
From within setup.py, shell execute
g++ -c iterator_traits_test.cpp
If it returns 0, add -DSTL_HAS_ITERATOR_TRAITS to CXXFLAGS.

This would work in conjunction with removing the default definition in
CXX_Config.h, and changing the conditional within that file to #ifdef
vice #if.  It would also virtually require using setup.py to build. 
Everything is a trade-off.

OTOH, if what I described is possible for the iterator thing, than it
could be used to capture all of our platform differences with only one
setup.py.

-Jonathan

Re: [Visualpython-users] History and Status?

[Arthur <ajs...@op...>]

> Consider for the moment the case of a complete turnkey bundle for
newcomers
> (ideally, a single installer for Python, Numeric, Visual and its docs and
> demos, idlefork until it gets into the regular Python distribution, and
less
> ideally two or three installers). A rather important piece of this is
> something that I don't see how to do with distutils, which is to provide a
> desktop shortcut (alias) to the editing environment (idlefork). This
> shortcut is created by the current VPython installer on Windows, which
also
> puts an entry on the Python section of the Start menu.

> Any ideas on how to address that in the distutils scheme of things?

distulis has the ability to trigger a post-install script, which can do
that.  I've seen it done in at least one distribution and we can pigeon - I
mean learn from ;) - that  distribution  precisely how it is achieved.
>
> A related question is whether there is a way in distutils to refer
> symbolically to the directory where Python is found (normally C:\PythonXX,
> but a user can install it anywhere). That would be a piece of constructing
a
> shortcut (alias). I even tried including a shortcut that could be dragged
> from site-packages\visual onto the desktop, but alas a shortcut must have
> absolute file references.

Not sure what you are asking here.  The installer does not assume any
particular location for Python.  I am not sure whether it searches the
directory tree, or refers to the windows registy entry - but it finds the
installation, and does not assume it is an any particular place.  But I am
not sure that addresses your question.

> It isn't absolutely necessary to find a distutils solution to this,
because
> there is really only one situation where this comes up, a novice-oriented
> bundled binary installer for Windows, and I can continue building such a
> thing using other tools, letting distutils handle all other situations
> (presumably in source form). I would however change the installation
> locations to those that Arthur and others have championed -- everything in
> site-packages\visual (visual, docs, demos, idlefork).
>
> Incidentally, I very hastily tried using the distutils installer on Mac
OSX
> in the X11 framework and was told, "gcc: cannot specify -o with -c or -S
and
> multiple compilations". I'm guessing this has to do with the
> "extra_compile_args" at the start of setup.py, which look like they're set
> for Windows?

The extra_compile_args are definitely Windows specific. Just so that people
understand, I'm clueless what they mean.  I simply mechanically followed
what was being done in the VC project files included with the source distro.

Or else it was I who actually wrote VC6.

I forget which. ;)

Art

Re: [Visualpython-users] History and Status?

[Arthur <ajs...@op...>]

> Any idea why distutils isn't an answer to these problems? Is it the
> dependencies in a source distribution on whether other libraries are
> present? I read Jansen's note and it doesn't mention distutils at all.

Not I.

Maybe Joe?

Art

Re: [Visualpython-users] History and Status?

[Joe H. <hea...@vn...>]

I forgot to mention that I have rudimentary knowledge of C, but C++ is 
a big mystery to me. In fact, my tiny and hopelessly incomplete 
understanding of OOP came from looking at VPython!

Cheers,
Joe Heafner

-----
I don't have a Lexus, but I have a Mac. Same thing.

Re: [Visualpython-users] History and Status?

[Arthur <ajs...@op...>]

Attached is a zip with 4 files.

1) The setup.py which has been tested under Windows and VC6.  It is
configured to do the install for which there seems to be some concensus - at
least as to Windows, .ie. it creates a directory under site-packages called
"visual" in which the cviusal.pyd and supporting .py files are placed and
then 2 subdirectories of  "visual" - one for demos, one for docs.

2) The Manifest file used for the source distribution

3) A README.txt which I put together if I were to do a separate, VPython
distributition off of the www.vpython.org site.

4) And an index.html - slightly modifed from the original.

In order for the setup.py to work, a particular organization of the
directories is necessary.  A "holding" directory for the setup.py, Manifest
and readme, and below it a "visual" directory, empty but with 3 separate
sub-directories - cvisual (with its subdirectories), demos, and docs. The
"docs" directory contains the attached index.html, and a "visual"
sub-directory with the rest of the VPython docs.

python setup.py bdist_wininst will compile the cvisual.pyd and create a
Windows self installing executable containing it and the rest of the files,
docs and demos.
python setup.py sdist will create a source distribution.
python setup.py install will compile and install VPython as described.

Feedback appreciated.

Art

Re: [Visualpython-users] History and Status?

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

I did ask about this at the time I was creating a Linux installer, and I
didn't get any clear answer. I was left with the impression that there is
quite a bit of flux in the Linux community. I think you should just poll
this VPython list for opinions and preferences; there seem to be plenty of
people reading this list who use Linux a lot. There doesn't seem to be one
right answer, so why not do what this group suggests?

The docs issue is an interesting one, in that here again there is quite a
bit of variation. For example, Windows Python comes with extensive
documentation, but at least in the past if I remember correctly Mac Python
didn't. I certainly want Visual docs to be included with Visual, at least
for most users, but maybe here again this is not okay with experts.

Bruce Sherwood

----- Original Message -----
From: "Arthur" <ajs...@op...>
To: "Gary Pajer" <pa...@in...>; "vpusers"
<vis...@li...>
Sent: Monday, February 17, 2003 6:39 PM
Subject: Re: [Visualpython-users] History and Status?


> > And I always look for packages in site-packages.  I think they all
should
> > be  there.
>
> That was my instinct, and exactly how I put together my current effort at
a
> distutils setup.py for Windows.
>
> But as I mention, there seems to be less concensus about what should be
done
> here. And the main reservation I have about this approach is that it seems
> to work better for Windows than Linux.  Though I am still trying to
> understand what other people doing with Linux Python module distributions.
>
> Numeric seems to have converted to an approach of 2 separate downloads,
one
> for the library files and one for the docs.
>
> I'd ask Guido for his opinion - if we were are speaking terms ;).
>
> Might you pose this to Guido, Bruce?
>
> Art
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] History and Status?

[Jonathan B. <jbr...@ea...>]

On Mon, 2003-02-17 at 21:49, Bruce Sherwood wrote:
> I did ask about this at the time I was creating a Linux installer, and I
> didn't get any clear answer. I was left with the impression that there is
> quite a bit of flux in the Linux community. I think you should just poll
> this VPython list for opinions and preferences; there seem to be plenty of
> people reading this list who use Linux a lot. There doesn't seem to be one
> right answer, so why not do what this group suggests?
> 
> The docs issue is an interesting one, in that here again there is quite a
> bit of variation. For example, Windows Python comes with extensive
> documentation, but at least in the past if I remember correctly Mac Python
> didn't. I certainly want Visual docs to be included with Visual, at least
> for most users, but maybe here again this is not okay with experts.


Here is one idea for Debian that looks consistant with other Debian
packages on my system.  I think that as binary debs, Vpython could be
installed in three packages, like this:

python2.2-visual:
	Install runtime shared object library and runtime scripts in 
	/usr/lib/site-packages/visual
	Install documentation in /usr/share/doc/python-visual

python2.2-visual-examples:
	Install the demonstration scripts in
	/usr/share/doc/python-visual/examples

(until no longer required)
python2.2-visual-idle:
	Install the scripts in /usr/bin/python-visual-idle
	, with a symlink from /usr/bin/python-visual/idle.py to  
	/usr/bin/vidle.py

The first package is the only one that someone must have to get started
with visual.  We can use the deb dependancy system to ensure that
Numeric, Tkinter, and Python2.2 are installed if required.  We can add
some remarks on the website that briefly explain what they are, although
I think that the package names are fairly self-explanatory.  

Can anyone confirm or refute similar behavior on other Linux
distributions?  Since I custom built my visual componants, I have
everything installed under /usr/local instead of /usr, using the same
scheme.

Arthur has convinced me that the right way to go for source and binary
distributions is to provide a setup.py (or other appropriate mechanism,
e.g, debs, windows exe) that does The Right Thing.  IMO, The Right Thing
is that which bears the same look and feel as other extension modules
for a given platform.  We may be able to provide binaries for only a few
platforms, so the source distribution must be clean.

As for the question, "Can the average non-programmer handle installing
many packages?" IMHO, _given proper instructions_, the answer is yes.  I
honestly do not see a connection between an inability to handle
dependancies, and a lack of programming experience.

-Jonathan

Re: [Visualpython-users] History and Status?

[Andy D. <dou...@la...>]

On Mon, 17 Feb 2003, Jonathan Brandmeyer wrote:

> Here is one idea for Debian that looks consistant with other Debian
> packages on my system.  I think that as binary debs, Vpython could be
> installed in three packages, like this:
> 
> python2.2-visual:
> 	Install runtime shared object library and runtime scripts in 
> 	/usr/lib/site-packages/visual
> 	Install documentation in /usr/share/doc/python-visual
 
> The first package is the only one that someone must have to get started
> with visual.  We can use the deb dependancy system to ensure that
> Numeric, Tkinter, and Python2.2 are installed if required.

One worry I have is that the versions required by VPython may not
necessarily match well with the versions supplied by the user's Linux
distribution.  As a specific example, the current 'stable' Debian
distribution (code name "Woody") has python-2.1.3 as its standard python.
I'm unclear whether or not a user can safely make '/usr/bin/python' be
python2.2 without possibly affecting other software installed on the
system.  In fact, in my experience with Vpython (which, admittedly, is
only 1 year long) the requirements of VPython (e.g. python version,
gtkglarea, numeric) have *never* been in agreement with the packages
available from my distribution.

Now I'm quite happy to install everything from source, so I always install
all vpython-related things into '/usr/local' or equivalent so as to not
overwrite the system versions.  If an automated Linux installation scheme
is going to update stuff in /usr/bin, then it had better do so with
extreme care.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042