Tarek Ziadé wrote:
2009/7/3 Paul Moore email@example.com:
Does this sound sensible? Tarek, would you be OK with me attempting to modify your prototype to support this protocol? Are there any tests for PEP 376, so that I can confirm I haven't completely broken something? If I can, I'll knock up some simple prototype importers for non-standard examples, and see how they work with all this.
Yes that's exactly what I was thinking about after the discussion we had in the other thread. This change would allow much more flexibility.
It's also very similar to the ideas that started to tick over in the back of my head after the previous discussion (only far more fleshed out that anything I got to - fortunately I read Paul's message before spending too much time on it!)
Specifically regarding this comment from Paul:
Finder.uninstall(distribution_name, filter=callable, installer=name) Uninstall the given distribution. It's likely that many finders will be read-only. In that case, this function should return None. Otherwise, return a list of the "files" removed. (This may need some clarification, as many finders won't have a concept of a "file name").
PEP 302 finders and loaders actually *are* expected to have a concept of a "file name". For Python modules they they are expected to have it so they can populate __file__ correctly (runpy is also a lot happier with them when they expose get_filename(), a relatively recent addition to the PEP 302 API). For other resources they're expected to have it so the get_data() API can work correctly.
One other thing to consider: it may be desirable to have hooks for meta_path and path_hooks in distutils that are checked *before* the full import hooks in the sys module. The reason I say this is that it would allow someone to override just the metadata retrieval (e.g. to pick up the extra dependency information saved by setuptools and friends) without having to worry about breaking the actual imports from those locations.
P.S. +lots on using 'metadata' in the PEP 376 method names rather than the jargon 'egginfo'. Jargon isn't always bad, but using it seems fairly gratuitous in this case.