On Sun, Jul 5, 2009 at 3:27 PM, Paul Moore
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