Re: [Visualpython-users] Mac installer

[Martin C. <cos...@wa...>]

Jonathan Brandmeyer wrote:
[]
>>You install fink, then ask to binary install visual-py23, and it 
>>installs all the other needed packages, including Python. The only 
>>slight glitch is that the Visual documentation isn't placed with the 
>>other Visual stuff in site-packages/visual but rather in 
>>sw/share/doc/visual-py23,
> 
> 
> This conforms with policies that are applied Fink-wide.  IMO it is
> entirely appropriate.

I could, of course, make a symlink in the python site-packages 
directory, or vice-versa, but there are more serious problems with IDLE 
and documentation, see below.

>> which IDLE doesn't point to. 
> 
> 
> Perhaps Mr. Costabel would be willing to add it in the fink package's
> post-install script? (see /sw/lib/python2.3/idlelib/config-main.def)

I have started to look at this, and I have a question: Right now, the 
idle_VPython module is not being installed (contrary to what the new web 
page seems to indicate). This is the default for python-2.3 as it seems, 
because there is already an IDLE module. Would it be useful to install 
this module or is it not advisable with python-2.3? Is it too broken?

I don't know much about IDLE, and there is still a bug in Fink's python 
package that prevents IDLE to read html documentation (it thinks 
dar'win' is a kind of windows OS). This is not hard to fix, but I am not 
the maintainer of the python package. The advantage of installing 
idle_VPython would be that I could easily configure this so that it 
finds the documentation and maybe fix the bug if it is there, too, or 
other bugs.

I have also been looking at vpython-3.0 on and off, too. It is not too 
hard to translate the mkdist_osx.sh script into a Fink package 
description. What keeps me from releasing a Fink package is that it 
needs a complete gcc and boost, and I am not yet clear in my mind how 
this should be related to other Fink packages. Is it acceptable that 
building vpython would use 600 MB of disk space and take 5 hours? I was 
  thinking of splitting it and have a separate gcc package, but this 
needs some more thinking.

-- 
Martin