PEP262 - database of installed packages

[A.M. Kuchling]

In article <a7gdg4$l5hni$1 at ID-59885.news.dfncis.de>, Thomas Heller wrote:
> +           THE (= Thomas Heller) thinks the first option. IMO a home
> +           page for the user is much more useful until we get something
> +           like to CPAN. Source distributions are platform and version

OK.  It should be really easy to have two URLs, anyway, one for the
home page and another for the latest package or a package description
file of some sort.

> +     THE: IMO typically a few dozen packages are installed, so we
> +     probably have less than, say, one hundred files in the 'database',
> +     which should reside in a single directory. Also it is not very

Agreed, though I think a few hundred packages is certainly possible.
Another thing has made it clear to me that invidual files are the
right way to go: installers such as RPM or DPKG.  They can just drop
the new database file into the database directory.  If one large text
file or a binary file were used, the Python database would then have
to be updated by running a postinstall script.

> +         THE comments: The uninstall 'database' (which is a simple text
> +         file) which bdist_wininst installers create, contain entries
> +         for *every* file to be removed, this includes .pyc and .pyo
> +         files. On the other hand, MD5 digests or CRC checksums are
> +         probably not so useful for .pyc/.pyo files.

Hmm... I suppose it could simply ignore checksums on .pyc/.pyo files,
so we don't need a type field to tell us when to ignore them.  I can't
think of any other generated files that don't need to be checksummed.


>           * XXX do we need to store permissions?  The owner/group?
> +         THE: no, not on windows.

Really?  Even on Windows, couldn't files be potentially owned by
Administrator or some other user.  We should definitely have
permissions and owner/group on Unix; can you tell me what Windows
needs here?  (I assume MacOS X would be the same as Unix, and earlier
MacOS versions aren't multi-user, so they don't need anything.)

>           * The file's full path, as installed on the system.  (XXX
>             should it be relative to sys.prefix, or sys.prefix +
>             '/lib/python<version>?'  If so, full paths are still needed;
>             consider a package that installs a startup script such as
>             /etc/init.d/zope)
> +           THE: Only full paths should be in the database file.

I had the vague idea that relative paths might make it easier to
relocate packages.  On the other hand, maybe that's not something we
want to encourage...

>           * XXX some sort of type indicator, to indicate whether this is
>             a Python module, binary module, documentation file, config
>             file?  Do we need this?
> +           THE: No, we don't need this. There is no mechanism (now) how
> +           this could be specified, also I cannot think of a use case
> +           where it would be needed.

Neither could I.  :) I'll remove this, unless someone can suggest a
use for it.

> +     THE: Maybe I don't understand what you are talking about here. I
> +     have absolutely no idea how RPM or DPKG is working, so I'm only
> +     talking about bdist_wininst or maybe other windows installers
> +     here. win32all and wxPython are examples of very popular packages

I was wondering whether an RPM package should bother to update the
Python database, as RPM provides much the same functionality; if you
already have one database, why maintain two?  But you're right;
updating the database shouldn't be optional, and therefore RPM will
have to update it.  Luckily that will be easy to packagers to support, 
because of the one-file-per-package database.

--amk                                                             (www.amk.ca)
This supports reflection, which is the 90s way of writing self-
modifying code.
    -- John Aycock at IPC7, during his parsing talk