> The problem issue remaining is recognising when we need to do this. In terms > of > code paths, pip install -U pip is no different from (for example) pip install > -U > flask. But it needs to be handled specially just because it's pip. And it > *doesn't* need to be handled specially if it's "python -m pip install -U pip". > That's not a Windows issue, though, I was just using the Windows issue to put > off having to think about it :-)
Not especially. You wouldn't want to do it for all files, but you can do the rename for all .exe files and then try and delete the .deleteme immediately. (Or you can try and replace and gracefully handle the exception.) As long as failing to delete the old .exe doesn't cause installation to fail, 99% of the time the end result is identical to now (and the other 1% is better, because install succeeded where it would currently fail). > One thought, while I have a Windows expert's attention ;-) Is there a way (I'm > not too bothered how complex it might be) of doing the equivalent of Unix exec > in Windows? That is, start a new process and then have my initial process exit > *without* the shell (or whatever started the first process) getting control > back > until the child completes? I'm assuming not, as otherwise solving the issue > would be as easy as exec-ing "python -m pip" from the wrapper. But no harm in > asking :-) I had this discussion with a colleague earlier today, and there really isn't. You'd need to be cooperating with the process that started you initially (cmd.exe/powershell.exe/whatever) and if there is a way to do it, (a) I don't know what it is, and (b) it's unlikely to be consistent/reliable/documented. At best, you could start a new process at the end of installation that keeps trying to delete the .deleteme file until it succeeds (or waits for a specific process to exit). However, my gut says that it's safer just to leave the file around and try and delete it later, especially since pip is going to be used in such a wide variety of contexts. Being clever is more likely to get you into trouble. Steve _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
