[PEAK] Packaging peak apps

[Bob Ippolito]

On Oct 8, 2004, at 5:46 PM, Phillip J. Eby wrote:

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

Why not put a PKG-INFO in there too, if it wants to specify something 
other than its parent package?  I don't really see much of a difference 
between one package and another, regardless of its place in the package 
hierarchy.. after all, sys.modules is flat.

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

For the application packaging use case, I don't think that really 
matters.  It's standard practice for a package to install everything it 
needs inside of its package, so only data files that end up in there 
are of my concern.  Any scripts, documentation, windows shortcuts, etc. 
that distutils installs aren't relevant my use case.

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

I remember your post, but I didn't pay much attention to the thread and 
how the issue was to be resolved.  If they're not going in 2.4, then we 
certainly shouldn't bother with them.

-bob