[Pythonmac-SIG] [Pythoncard-users] Re: Python based apps woes on MacOs X (was :Re: [Pythoncard-users] Re: PythonCard on OS X 10.4 with Python 2.4.1)

[Kevin Altis]

On Sep 4, 2005, at 4:10 AM, Alex Tweedly wrote:

> Ronald Oussoren wrote:
> Thanks Ronald. I hadn't spotted that this was still being cc'ed to 
> pythonmac-sig - so extra thanks for that.
>
>>
>> I haven't followed this discusion upto now, but do you use py2app to  
>> build the application bundle on OSX? py2app places all .py/.pyc files 
>>  into a zip file, resources are outside of the zip file.
>>
> No, these problems are also being seen within the IDE, so it's not an 
> app/bundle problem.
>
>> BTW. do you know about setuptools? It contains a generic API for  
>> dealing with resource files.
>>
> Yes, and that looks like a promising way to do this in the future. 
> (though it increases the dependencies).
> But this code has existed and worked for a couple of years now, it's 
> important we know what's going wrong with it in case there are other 
> (less obvious) things that are going to fail for the same reasons.
>
>>> So - that's the background.
>>>
>>> Brad sent the debug output from the first case above (before  
>>> Kevin's suggested change), and also reported that the problem  
>>> persisted after the change. So it looks likely that it's a Python  
>>> bug. The Python docs are very sparse on what sys.modules should do.
>>
>>
>> I'd say it is unlikely to be a bug in Python :-)
>>
> So would I - but the evidence up till this email all pointed that way 
> - and since this is (perhaps) an unusual use of the sys.modules info, 
> it seems just possible.
>
>>>
>>> I'd like to see a simple test output which is independent of  
>>> PythonCard.
>>>
>>> < snip >
>>
>>
>> For what it's worth:
>>
>> Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
>> [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import sys
>> >>> from mmm import myFile
>> >>> myFile.myClass.__module__
>> 'mmm.myFile'
>> >>> myFile.__file__
>> 'mmm/myFile.pyc'
>> >>> sys.modules[myFile.myClass.__module__].__file__
>> 'mmm/myFile.pyc'
>>
>> and:
>> Python 2.4.1 (#1, Aug 23 2005, 21:38:15)
>> [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import sys
>> >>> from mmm import myFile
>> >>> myFile.myClass.__module__
>> 'mmm.myFile'
>> >>> myFile.__file__
>> 'mmm/myFile.py'
>> >>> sys.modules[myFile.myClass.__module__].__file__
>> 'mmm/myFile.py'
>>
> Thanks again for that.  (Not quite was I was hoping for :-), but very 
> valuable info).
>
> So we now know this simplest case works as expected - and the rather 
> complex case within PythonCard doesn't.
>
> It should be straightforward (if somewhat tedious) to narrow down the 
> differences until we find where the difference is. But that's not the 
> kind of debugging we can do via email on a list (or two!!), so I'm 
> hoping a PythonCard / Mac user can take it from there (or will contact 
> me off-list and we can work on narrowing it down).
>
> -- 
> Alex Tweedly       http://www.tweedly.net

I expect the problem has to do with relative paths. For some reason 
Python 2.4.1 is behaving different from 2.3 on the Mac as well as 2.3.x 
and 2.4.x versions on Windows and Linux. The reason why PythonCard 
tickles this problem is likely due to one or more lines in model.py. In 
particular, at the top there is a try/except block with the following 
line that was added as a fix for relative paths that would show up in 
earlier versions of Python when the module was imported:

     sys.path[0] = os.path.abspath(sys.path[0])

There was a discussion on python-dev quite a while ago that led to this 
line of code being used to prevent relative path ambiguity with the 
module path regardless of how the application changes its working 
directory. Here's an example run in the shell on the Mac with Python 
2.3 (Panther).

 >>> import sys
 >>> sys.path[0]
''
 >>> import os
 >>> sys.path[0] = os.path.abspath(sys.path[0])
 >>> sys.path[0]
'/Users/kea/python/PythonCard'

PythonCard does an explicit os.chdir later to the starting script 
directory to standardize behavior of apps regardless of where they were 
started from as well as simplify using support files, including modules 
that are in the application directory or sub-directories.

         self.applicationDirectory = 
util.dirname(os.path.abspath(sys.argv[0]))
         # always run in the app's directory
         os.chdir(self.applicationDirectory)

Both of these bits of code, or equivalent in the case of the chdir 
above need to be part of a test prior to the path check for __file__. 
Since this is a relative path bug we're tracking down, it is quite 
possible that with Python 2.4.1 on the Mac you could get different 
results depending on whether you are running the script from the same 
directory you are working from in the shell, that was the reason for 
the sys.path[0] workaround in the first place.

ka