[Pythonmac-SIG] #! line and simple dialogs [SOLVED]

[Bob Ippolito]

On Oct 2, 2004, at 2:51 PM, has wrote:

> Kevin Altis wrote:
>
>>> I actually meant dependencies for the casual scripter, not the
>>> end-user.  I'd love to be able to tell my friends, "Python makes an
>>> elegant replacement for AppleScript for your simple scripting tasks
>>> and you only need to install 1 package to make it work."  If
>>> EasyDialogs was just a little better it would already be true! :-)
>>> If/when appscript and/or PyObjC get into the core then the argument
>>> would become even simpler and much more convincing.
>>
>> It is possible that Apple will include the current versions of 
>> PyObjC, wxPython, and/or appscript with Tiger, but I wouldn't count 
>> on it and it still won't solve the problem on Jaguar or Panther. 
>> There isn't a whole lot of difference between installing PyObjC and 
>> wxPython from a user standpoint, they both are distributed as disk 
>> images and get installed by double-clicking a package file. Of 
>> course, you could use the PackageManager as well, but that has other 
>> problems. AFAIK, appscript is orthogonal to the issue of whether you 
>> do the GUI via wxPython or PyObjC even if that GUI is a linear series 
>> of steps and only uses dialogs for input. For scripting other 
>> applications appscript certainly seems easier to use than PyObjC from 
>> the examples I've seen and used myself. So, I think you're going to 
>> want to install two packages, but neither are hard to do and it will 
>> work on different versions of Mac OS X.
>
> As a tangent to your orthogonal, would it make sense if Apple's 
> MacPython installation had its site-packages folder at, say, 
> /Library/Python/site-packages, instead of deep inside the perennial 
> no-go area that is /System?

It does.. essentially.  /System/.../site-packages is a symlink to 
/Library/Python/2.3.  The sys.path points to 
/System/..../site-packages, so that's what most people see (in 
tracebacks, etc.).

> Might also fit with something I remember Jack talking about some time 
> back - maybe moving some of the Mac-specific modules out of the 
> standard distribution and provided as a separate add-on package, 
> allowing them to be dealt with as a separate ongoing concern rather 
> than tied to the development cycle of MacPython.framework.

This is what the win32all / py2exe projects do.  I'm not against it, 
but Apple might not end up including these "optional" modules in OS 
releases.  I'm not really sure if this is better or worse than the 
current situation.

-bob