[Pythonmac-SIG] New Page, first proposal

[Bob Ippolito]

On Feb 9, 2006, at 5:09 PM, Christopher Barker wrote:

>> "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?

No

>> 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?

Not that I can imagine... maybe a few nanoseconds wasted on  
invocation to launch the executable and execv the real interpreter.

> 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'd prefer to wait on that until it's more mature.  Shipping  
setuptools isn't a bad idea, but it's a one-liner to install it..

> 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.

Some Apple employees do a pretty good job at working with open source  
communities when they have the time to do so.. but they're usually  
too busy, and it's really their own initiative.

Personally I haven't been very pleased with their open source  
interactions, but it could be worse.

> 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?

The universal version is indeed not compatible with 10.3.0-10.3.8,  
but upgrading to 10.3.9 is free.  I think it's safe at this point to  
say 10.3.9 is absolutely required to use the supported version of  
Python.

The extension thing we can hack around by installing two copies of  
the Makefile and having distutils pick a PPC-only Makefile if it  
detects 10.3.

>> 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.

It might be a good idea to highlight the really frequent FAQs and  
link to their answers on the wiki.

>>  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.

Well we might as well just crib the script from DarwinPorts and  
change the paths... supporting tcsh is important for the people who  
started with <= 10.2 and upgraded their way to >= 10.3.  I held out  
with tcsh for a while personally, but I left it at bash last time I  
AppleCare'ed my powerbook and wiped the machine.

-bob