[PEAK] Packaging peak apps

[Phillip J. Eby]

At 04:58 PM 10/8/04 -0400, Bob Ippolito wrote:

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

My point was more that the needed info could be generated from that into a 
file, such as in PEP 262 or your proposal below.


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

Hm.  There's an interesting thought.  Except... what about nested packages?

Also, there's no easy way to find *all* the files installed by a 
"distribution", or to remove them, unless there's also a PACKAGES section 
or something.  It also won't really let you verify that you're not missing 
things.


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

The ones in 2.4 are going to be removed before 2.4 final; perhaps you've 
seen my post on Python-Dev about that?