[Distutils] Installing packages using pip

Wayne Werner waynejwerner at gmail.com
Mon Nov 16 10:04:50 EST 2015


On Mon, 16 Nov 2015, Paul Moore wrote:

> On 16 November 2015 at 13:12, Wayne Werner <waynejwerner at gmail.com> wrote:
>> Windows file locking is the worst. But it *is* possible to get around - see
>> the program called BareTail.
>
> Windows file locking is just complex, and the defaults are "safe"
> (i.e. people can't change a file you have open). As you say, you can
> use different locking options with the Win32 API, but because core
> Python's file API is basically derived from Unix, it doesn't expose
> these options.
>
> It wouldn't help here anyway, as it's Windows that locks a DLL when
> you load it. Personally, I don't see why people think that's a bad
> thing - who wants someone to modify the code they are using behind
> their back? (I don't know what Unix does, I suspect it retains an old
> copy of the shared library for the process until the process exists,
> in which case you'd see a different issue, that you do an upgrade, but
> your process still uses the old code till you restart).

This is the case for all files. To check, simply open two terminals and in 
one:

     echo "Going away" >> ~/test.txt
     tail ~/test.txt

And in the other:

     echo "You will not see this" > ~/test.txt

But tail has an option `-f` that will follow the file by name, instead of 
I presume it't the inode. Of course if you >> append to the file instead, 
tail *will* actually pick that up.

> Long story short, modifying code that a process is using is a bad
> thing to do. Therefore, the fact that pip can't easily do it is
> probably a good thing in reality...

I suspect it makes life simple (which is better than complex). My personal 
assumption about DLL loading would be that it would follow the same 
pattern as Python importing modules - it's loaded once from disk at the 
first time it's imported, and it never goes back "to disk" for the orignal 
DLL.

Though I can also understand the idea behind locking ones files, I kind of 
put that in the same basket as a language enforcing "private" variables. 
It just increases the burden of making that particular choice, regardless 
of how appropriate it may (or may not) be.


I suppose that's mostly academic anyway - I'm not sure that invoking pip 
from within the repl is *really* the best solution to getting packages 
installed into the correct Python anyway.

-W


More information about the Distutils-SIG mailing list