[Pythonmac-SIG] New Page, first proposal

[Christopher Barker]

Hi all,

Lots of comments on the whole thread....

Bob Ippolito wrote:
> Nothing relevant comes with the system except for Terminal and  
> TextEdit...

Which is a lousy editor for Python anyway.

Brendan Simons wrote:
> SPE is almost  there, but still needs a binary install.

Would it be there with a good installer?


>> BTW, "Open Terminal Here" is a nifty applet

> Here's another easy way to do the same thing:  Open the terminal.   
> Type "ls" followed by a space, but don't hit return.  Now click on  
> the finder and open the folder you want Terminal to access.  In the  
> titlebar of the finder window, next to the folder's name, is a little  
> folder icon.  Drag that icon to your terminal window (Expose helps if  
> you have lots of windows open).  Terminal will spell out the folder's  
> path for you.  Now return to Terminal and hit enter.

I now about that, but that's a LOT more than one click -- get Open 
Terminal Here -- you'll be glad you did!

Bob Ippolito wrote:
> The 95% may shrink now that wxPython and tkinter are shipped with Mac OS 
> X.

Except that the version of wx they ship isn't one anyone should use it 
they can help it. wxPython was a rapidly moving target on OS-X when they 
chose that version.

>  further still if PyObjC ends up shipping with 
> some version of OS X.

That would make a big difference.

>> If I was building an app that was written in Python, given the current
>> state of MacPython and what I've read on this list over the years, I'd
>> try to include the whole Python VM in that app bundle.

Which means you need to use a user installed python.

Bill Janssen wrote:
> I think here you are talking about a Mac app bundle, right?  I think
> that's probably right.

It applies just as much to a script with a #! line that relies on 
installed packages. Do you really develop without any external packages?

Kevin Ollivier wrote:
> I'd get really pissed off if I didn't know better and things stopped 
> working regardless of how I upgraded Python. You'd consider whose Python 
> broke your stuff into your decision to get upset?

We really seem to be talking at cross purposes here. If I upgrade 
*python*, I expect things that depend on it to break, though in fact, 
when I upgrade python, I usually leave the old version in place so that 
nothing breaks. I put a version in my #! lines just for that reason.

However, when I upgrade OS-X, I want my currently installed apps to keep 
working. And, in fact, they do, except the ones that depend on python. I 
just upgraded to OS-X 10.4. For ages, I've been using both Apples 
python2.3 and Bob's 2.4. All my scripts that have #!/usr/bin/env 
python2.3 in them are now broken. All the scripts that have 
#!/usr/bin/env python2.4 in them still work. If I'd started with 2.4 
from the beginning, nothing would have broken. It's not hard to fix, 
particularly since I have a fully functional 2.4 already, but I'm not a 
newbie, either.

> All Apple is doing is including Python with their OS, and occasionally 
> updating it. That these updates can cause not-so-pleasant things to 
> happen due to how Python works is not Apple's fault. A lot of the speech 
> on here practically accuses Apple of causing the problem and it's really 
> not fair.

What they are doing is analogous to removing a bunch of shared libraries 
when you did an OS upgrade. IF you knew they were likely to do that 
you'd darn well better statically link your apps.

> tell them things break when Python is upgraded 
> to a new major version; don't tell them (or suggest) things break 
> because Apple is doing it.

Tell them that Apple is likely to upgrade python for you when you 
upgrade the OS, whether you want them to or not. however -- that's all 
we're saying.

> What about an app bundle that just starts IDLE?

Yes, we should make one of those!

Kevin Walzer wrote:

> No one has said anything about the "applet" packaging concept as we
> discuss moving forward with this stuff.

I'd like a way to build Applets: things that look like an App, but do 
depend on everything installed in your python. It probably wouldn't be 
hard to hack Py2App to do this. IIRC, Bob was open to the idea, but 
wasn't interested in writing the code himself.

> "pythonw" invokes GUI applications, "python" invokes console
> applications. When installing an extension, I don't type "pythonw
> setup.py install."

But would there be any harm if you did?

> If we recommend that the user installs a particular framework build  
> of Python, we could distribute it such that python and pythonw are  
> indistinguishable.  This issue then disappears.

Excellent idea! Is there any downside in having "python" do what 
"pythonw" does now?



Rodney Somerstein wrote:

> Now, what I really want to see added is something that explains how I 
> can write a program in Python on the Mac and create standalone 
> applications that can run on someone else's computer without them 
> having to install anything else.

Let's have py2app be a standard part of the 2.4 package. It'd be great 
if the standard upgrade package had and did everything you need to get 
started. I suggest easy-install as well.

I. Vinogradov wrote:
> What about other sources for python2.4 such as fink and darwinports?
> Will they be frown upon or required to comply with framework
> installation? 

We can't require a darn thing about fink or darwinports. They should be 
mentioned, under something like:
If you are using fink or darwinports for other unix-y software....
or
If you want to have complete unix-y environment in your Mac....

Bill Janssen wrote:
>  and there's not even a useful web page for MacPython.

At least we're fixing that! Thanks for all your work, Bill.

>  Is there anyone from Apple even on this list?

non one that has admitted it -- earlier there was a discussion about 
whether Apple was to blame for any of these issues. they clearly are, as 
they don't ever have anyone on this list. I don't think Apple has really 
figured out how to work with the open source community yet.

> I've got a great deal of respect and appreciation for those, like Bob
> and Ronald, working hard on advancing the technology pieces.  Great
> work, just what we all need!  But unless there's some effective
> delivery vehicle for getting that work to the customer, much of it
> will be wasted.

Bob's always made easy to install packages of his builds -- it could be 
better, but it's there, and far from wasted. Also, patches get into the 
main python source, and even Apple gets those eventually!

It's just not that bad. All we really need is a couple better web pages, 
and a few more pre-built packages, and we'll be serving all but the 
total mac-centered newbies. What those folks need is a complete 
environment with a single installer.

Bob Ippolito wrote:

> If we ignore the vendor's interpreter then our documentation becomes  
> MUCH simpler as there will be one -- and preferably only one -- way  
> to do it:

This has been my point from the beginning. There are a LOT of options, 
but we really need to have a "One Standard Way" to do python on the Mac 
that we publicize on the Web.

A little extra into-tutorial with the built in Python is a fine way, but 
I think it should be clear that it's a good idea to install a new python 
package once you get going. That way there is ONE set of packages to 
pick from to download, etc, etc.

I'd like the "One true way" to be the Apple installed python, but that's 
really not going to work. We've run that topic into the ground.

We may still need one version for 10.3 and one for 10.4, but that's as 
complicated as it should get.

> We also get to ignore the issues  
> of which version of Mac OS X they are using because 10.3 and 10.4  
> will behave the same.

Um, aren't there issues with not being able to use the universal version 
with less than 10.3.9, and not being able to build extensions on 10.3 at 
all with the universal version?

> Our problem with Apple's bundling of Python is purely a documentation  
> issue (and the stubbornness of those who insist that it should be  
> used -- even celebrated -- despite its disadvantages).  If we make  
> the proposed PATH change script to the installer, we can ignore the  
> system Python just as easily as we could if it wasn't there at all.

yea!!

> Some of these questions are already answered by http://pythonmac.org/ 
> wiki/FAQ -- for the questions that aren't currently answered, feel  
> free to contribute.

Exactly. the page we are working on should be just the main page. All 
the various suggestions for other sections are good, but should be Wiki 
pages, maintenance is much easier that way.

>  check if /opt/local/bin is in the path, if not,
> then append a line to their .cshrc if their SHELL is *csh and append  
> a line to their .profile if their SHELL is *sh.

We could probably just do .profile...anyone messing with what shell they 
use should know how to add something to their PATH.

Wow! that was a lot.

I hope I'll have some time to really comment on Bill's prototype page 
tonight.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov