[Pythonmac-SIG] Trouble with MacPython 2.3 on 10.2.6 (Solved!)

[Bob Ippolito]

On Thursday, Aug 7, 2003, at 12:27 America/New_York, Adam Augustine  
wrote:

>
>
> Bob Ippolito wrote:
>
>> On Thursday, Aug 7, 2003, at 11:42 America/New_York, Adam Augustine  
>> wrote:
>>>
>>> Bob Ippolito wrote:
>>>
>>>> On Wednesday, Aug 6, 2003, at 20:01 America/New_York, Adam  
>>>> Augustine  wrote:
>>>>
>>>>> So I have done an "ln -s Python python" and now everything seems  
>>>>> to be  working properly.
>>>>>
>>>>> Anyway, thanks for the help. I am putting some search terms for  
>>>>> the  benefit of those who come later since most of the initial  
>>>>> error  messages are now edited out of the message.
>>>>>
>>>>> execle returned, err=22 console error message PythonIDE  
>>>>> PackageManager  BuildApplet
>>>>
>>>> Are you using HFS (Mac OS Extended), or UFS?  Sounds like you might  
>>>> be  using UFS, I don't think anyone tested that.
>>>> -bob
>>>
>>>
>>> You are correct, I am using UFS. I am happy to test, because, hey-  
>>> free programming language. :-)
>>>
>>> Are there more tests I should do to help the project along?
>> Well that was it!  Here's what happened:
>> The python executable (in the application bundle used to run GUI  
>> scripts) used to be lowercase
>> It was renamed Python to meet Apple guidelines
>> The she-bang lines for the GUI scripts were not also changed because  
>> worked on HFS and nobody noticed (HFS is not case sensitive)
>> -bob
>
> Yeah, I could have simply changed the she-bang line for all the  
> relevant apps, but I thought, since MacPython doesn't look to be  
> completely case-clean and probably can't reliably be so because of  
> HFS, that the symbolic link was a better (read: easier for my lazy  
> self to implement) solution.

It should be pretty much case clean, the only place where it might not  
be are in those GUI bundles, as you've seem.

> I know most people on other Unixes (Unicies, Unixii?) expect lowercase  
> "python" executable names, but those are usually /usr/local/bin type  
> places (which are already "as-expected") and not deep in the bowels of  
> a framework. It makes sense to follow the Apple guidelines.

It is a lowercase python executable everywhere that would be relevant  
to unix (/usr/local/bin/python*,  
/Library/Frameworks/Python.framework/Versions/2.3/bin/python*)

It should, by convention, be a Capitalized exectuable everywhere that  
would be relevant to WindowServer  
(/Library/Frameworks/Python.framework/Versions/2.3/Resources/ 
Python.app/Contents/Resources/MacOS/Python)
This is a fake application bundle that lives inside the Python  
framework.  I don't have time to fully explain why, but basically the  
deal is that WindowServer has a bug/feature in that it will not like  
you unless it finds an application bundle at (the  
on-the-top-of-the-executable stack equivalent of)  
os.path.split(os.path.split(sys.executable)[0])[0] -- except it uses  
methods less intelligent than sys.executable to figure this out, so it  
also breaks in even more situations (executed from a shell script,  
executed from $PATH, executed from a relative path, executed from  
symlink, etc).  Without this application bundle, and the pythonw script  
you would have a very hard time executing GUI python applications  
without calling into private Apple APIs (which I figured out how to do  
two years ago, but it's still discouraged) or creating an actual  
application bundle for any script you would like to execute.

> It seems to me that the execle returned, err=22 message was pretty  
> misleading.

As far as I could tell, it should've returned ENOENT (2), not EINVAL  
(22) according to the relevant man pages.  Maybe we should look into  
this a bit more and file a bug against Darwin?

-bob