[PEAK] Packaging peak apps

[Bob Ippolito]

On Oct 8, 2004, at 3:40 PM, Phillip J. Eby wrote:

> At 03:23 PM 10/8/04 -0400, Bob Ippolito wrote:
>
>> There is currently no standard way to determine what files a package 
>> actually *needs*, versus what files happen to be in there (such as 
>> documentation, version control junk, etc.)... so correctly packaging 
>> up stuff that requires data files is going to require developing some 
>> manifest file or something that says "i need these files".  
>> Preferably this file would be parseable without eval'ing arbitrary 
>> python code.
>>
>> If you come up with something that makes sense, I'll support usage of 
>> it in py2app and try and get it supported by at least Twisted and 
>> pygame.
>
> Well, for the application being generated, the setup.py will specify 
> what "package data" files are valid, so in the case of py2app you can 
> just use the distribution object's data to get at that.  The build_py 
> command handles generating the actual list.

Well py2app wouldn't have access to PEAK's setup.py at the point where 
it wants to determine the dependencies for the peak package.

> For already-installed packages, PEP 262 defines an installation 
> manifest that would record the data, and in principle should 
> eventually be implemented for package data files.
>
> So, my suggestion would be to implement PEP 262 as an add-on to 
> 'setuptools', and then we're good to go.  ;)

The problem with PEP 262's installation database is that it's not 
flexible.  The metadata in this case belongs inside the packages, not 
in a separate database.  If there is a separate database, it should 
have its own sys.path and import hooks..

How about we just make a file named PKG-INFO inside every installed 
package that contains the typical PKG-INFO information and FILES 
section?

> Of course, to do that, we'll probably need to hash some things out on 
> the Distutils SIG.  I think I'd want to propose dropping the REQUIRES 
> and PROVIDES sections, and of course all my "open issues" listed in 
> the PEP.
>
> What do you think?

I think REQUIRES and PROVIDES are a good thing, at some point, 
especially for package management and application packaging uses.. but 
in this case I don't think the ideas as implemented in Python 2.4 are 
mature enough to bother with for this use.

-bob