[Pythonmac-SIG] New Page, first proposal
Chris.Barker at noaa.gov
Fri Feb 10 02:09:54 CET 2006
Lots of comments on the whole thread....
Bob Ippolito wrote:
> Nothing relevant comes with the system except for Terminal and
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
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
> 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
> 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
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....
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.
> 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
Christopher Barker, Ph.D.
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
More information about the Pythonmac-SIG