[Distutils] Re: Package DB: strawman PEP

[Andrew Kuchling]

[Picking up the package-DB thread from last week]

On Mon, Jul 09, 2001 at 03:17:35AM -0400, Daniel Berlin wrote:
>This can easily be rebuilt in case of corruption, since *it* was
>generated initially by scanning the files (you just keep it up to date
>when you install packages, and if something gets out of whack,
>completely rebuild it).

The real package database implementation will very likely build a
cached version of the data using anydbm or some faster mechanism.  I
don't think the PEP needs to specify that, though if people disagree
it could certainly be added.  I 

>>         An initial line listing the sections in this file, separated
>>         by whitespace.  Currently this will always be 'PKG-INFO
>>         FILES'.  This is for future-proofing; if we add a new section,
>>         for example to list documentation files, then we'd add a DOCS
>>         section and list it in the contents.  Sections are always
>>         separated by blank lines.  XXX too simple?
  ...
>>     Each file's entry is a single tab-delimited line that contains the
>>     following fields: 

>Can we try to keep delimiters the same where possible (IE why use
>whitespace here, but tabs for file entries)?  

Fair enough; I was thinking the information for a single file is small
enough, and easy enough to get right initially, so it shouldn't need
extending later.  Perhaps RFC822-style should be reused again to list
files:

Name: /usr/local/lib/python2.1/site-packages/mymodule.py
Mode: 0644
Size: 565
Digest: 01abcdef...
Name: /usr/local/lib/python2.1/site-packages/mymodule2.py
Mode: 0644
Size: 1024
Digest: 02fedbca...

There should be blank lines to mark the end of each file's stanza, but
that breaks the idea of using blank lines to indicate the end of a
section.  Perhaps the 'Files' section should simply always come last,
and therefore safely break that convention.

>>owner/group will get you in trouble if the owner/group doesn't exist
>on the other system.

Good point.

>>         * XXX some sort of type indicator, to indicate whether this is
>>           a Python module, binary module, documentation file, config
>>           file?  Do we need this?
>Well, it would allow you to purge docs seperately from the rest of the
>package, or purge everything but the config files. I've used both
>options myself. The other option is to put docs in a seperate package.

Docs in a separate package is unlikely, so I suppose we need to use a
type indicator.  

--amk