[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