On Sun, Jul 5, 2009 at 3:27 PM, Paul Moore<p.f.mo...@gmail.com> wrote: >> >> A concrete proposal would be to take back your proposal, but return >> tuples with the location as the first member. >> e.g. "(location, relative path[s])" > > That sounds reasonable. So we can forget the "local" parameter, and > return a tuple: > > - absolute location of the container (directory, zipfile or whatever > containing the egginfo file) as a filesystem path in canonical native > form (where it's filesystem based) or as an opaque token for the odd > cases (frozen modules, for example) where a filesystem location isn't > available. > - entry from the RECORD file, as a slash-separated filename relative > to the root of the container.
exactly, > > But if you're using get_installed_files(), why would you then want to > read the files? What exactly would you *use* get_installed_files for > which would then leave you needing to read the files? If it's to check > they haven't changed (by comparing md5 values) you're doing that to > uninstall, so that's the responsibility of the uninstall function. > > Again, it's a question of what is a public API, and what is the use > case it's designed for. Right. These APIs were created for third-party package managers. One use case of a package manager is the uninstallation, but I have no other use case in mind. > > I'm currently writing a SQLite importer, which will allow me to store > "files" in any sort of database tables I want, so I can build in some > nice pathological behaviour. That should tease out some awkward corner > cases :-) Sounds good. Semi-related: even if the files themselves are in the filesystem, having a sqlite db to index the list of installed distributions makes a good cache solution to reduce the disk I/O and speed up the query functions. So maybe we could use a disk-based cache for site-packages-like directories in the form of a sqlite db. That's what I am experimenting on my side. > > Paul > -- Tarek Ziadé | http://ziade.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
