Paul Moore wrote: > To be honest, this is a major can of worms. But if PEP 376 is not > going to support PEP 302, then it must state that fact explicitly, to > avoid giving people false expectations - particularly with Brett's > importlib in Python 3.1, which will make it far easier for people to > experiment with new packaging formats such as the ones Lukasz mentions > above. And it MUST fail gracefully in the face of unsupported importer > types.
importlib is in 2.7 as well. I agree that even if the reference implementation of PEP 376 only handles normal directories and zipfiles, the PEP itself needs to explain how the developer of a custom PEP 302 importer or loader can hook into the mechanism in order to provide metadata that distutils can understand. Or, as you suggest, state explicitly that the proposal at this stage is specifically limited to filesystem and zipfile packages and defer extension to arbitrary PEP 302 importers and loaders to a later PEP. To be honest, I'd personally be OK with the latter strategy - while other PEP 302 loaders and importers do exist (as Lukasz'z post shows), it would be unfortunate to unduly hold up improved installation metadata for the vast majority of typical use cases while we try to figure out ways to support the more esoteric use cases. Supporting both would obviously be better, but given the choice between the status quo and partial support, I believe this is a case where the partial support would still be worthwhile. I will note (and I believe this is also the main point that Lukasz was making) that having the distribution metadata outside the distribution as currently proposed in PEP 376 is going to make any eventual PEP 302 integration much harder - 302 importers only provide a mechanism for accessing files inside the distribution, not "adjacent" to them, so the mechanism in the PEP doesn't generalise properly. I suspect this limitation of the PEP 302 APIs is the origin of the setuptools format that embeds the metadata inside the distribution - it lets you get at the metadata without having to assume that it exists directly on the filesystem anywhere. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
