
FWIW, Windows (by default) has a regular maintenance task that will clean up old files in the TEMP directory. I think the default settings will delete files older than 30 days and more aggressively if disk space is running low. I'd say pick a consistent/static subfolder ('wheel_mount_35_amd64' or something), autogenerate whatever is needed within there, and leave it behind. Users who are concerned can rm -rf whenever they like and everyone else can let the OS handle it. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Paul Moore<mailto:p.f.moore@gmail.com> Sent: 1/30/2014 14:52 To: Nick Coghlan<mailto:ncoghlan@gmail.com> Cc: DistUtils mailing list<mailto:distutils-sig@python.org> Subject: Re: [Distutils] distlib.mount API design (was: wheels on sys.path clarification (reboot)) On 30 January 2014 22:38, Nick Coghlan <ncoghlan@gmail.com> wrote:
The advantage of wheels over plain zipfiles for this use case is the structured metadata. distlib.mount doesn't try to guess the package structure for the extensions, you have to provide an EXTENSIONS file in the metadata that explains what C extensions are present and how they should map into the module namespace.
OK, I think I get the idea now. I'm still not comfortable with the temp directory clutter that unpacking leaves (in particular on Windows where deletion isn't even possible in an atexit routine) but I'll survive. I *would* like to see the various technical issues and implications in the API documentation, though. The implications and limitations, and in particular the manual cache management requirements, need to be made explicit. (I thought I'd seen docs somewhere, but they definitely aren't in the API reference for the distlib.wheel module). Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig