[SciPy-dev] Issues "freezing" scipy using py2app

Josh Marshall josh.p.marshall at gmail.com
Thu Dec 22 02:16:58 EST 2005


On Wed, 21 Dec 2005, Pearu Peterson wrote:

>> I have an application that is using PyObjC, matplotlib and scipy to
>> perform some image classification and feature extraction. I am now
>> attempting to use py2app to bundle it up into a single OS X .app.
>>
>> ...
>
> Thanks for the patch. I have applied it to new pkgload feature.  
> scipy does
> not use _import_tools.py anymore.

As soon as this is available in SVN I will test it out.  Not using  
_import_tools.py should make it easier to package the app. I will see  
how I go.

>> There must be a simpler way, such as using find_module, but I
>> couldn't get this to work since it requires the parent package to be
>> imported before the subpackages.
>
> info.py files should be regarded as information files about  
> packages, they
> are python modules only for convinience. And using imp.load_module is
> necessary to prevent importing the whole package, at the import  
> time we
> need only the information from the info.py file.

I think it is a good idea to hold this information in python modules.  
If it is held in a data file, this becomes problematic with regards  
to the different ways of distributing scipy, eg install from source,  
frozen in a zip. This is similar to the problem matplotlib had with  
where to put their data files. Keep as is, works well.

>> 2) The second issue was a problem involving get_config_vars being
>> called from ppimport.py. distutils then requires the presence of the
>> Python config file, which doesn't exist in the bundle.
>>
>>  This was easily fixed by adding
>>
>>         if sys.platform[:5]=='linux':
>>             so_ext = '.so'
>> +        elif sys.platform=='darwin':
>> +            so_ext = '.so'
>
> Hmm, what exception do you get when Python config file is not present?
> ppimport._get_so_ext uses so_ext='.so' when ImportError appears.
> I think the proper fix would be to catch proper exception.

It was a problem related to trying to include the entirety of  
distutils in my packaged application. The exception came from  
distutils. I will try catching the exception and see if this is a  
valid fix.

>> 3) Finally, I can't distribute my .app as-is, after being generated
>> by py2app. py2app operates by all needed modules from the system  
>> site-
>> packages being collected into a "site-packages.zip" within the
>> application bundle. At runtime, some magic with import causes
>> everything to work, and this is where scipy falls down. When trying
>> to import the subpackages using the _import_utils.py magic, it cannot
>> find them within the site-packages.zip. I can fix this by
>> distributing the .app with the site-packages.zip expanded into a
>> directory. However, I was wondering if anyone who knows the import
>> magic better knows if we can fix this.
>
> I'd like to learn more about the magic that Python does with .zip  
> files.
> Are there similar issues when using eggs?

I will look into this after the Christmas break. It would be nice to  
be able to package scipy as an egg, and also create a proper Mac  
installer.

  Merry Christmas to all.
Josh




More information about the SciPy-Dev mailing list