[Python-Dev] Proposal for virtualenv functionality in Python

Ian Bicking ianb at colorstudy.com
Sat Feb 20 20:41:45 CET 2010


On Fri, Feb 19, 2010 at 10:39 PM, Glenn Linderman
<v+python at g.nevcal.com<v%2Bpython at g.nevcal.com>
> wrote:

> On approximately 2/19/2010 1:18 PM, came the following characters from the
> keyboard of P.J. Eby:
>
>  At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
>>
>>> I'm not sure how this should best work on Windows (without symlinks,
>>> and where things generally work differently), but I would hope if
>>> this idea is more visible that someone more opinionated than I would
>>> propose the appropriate analog on Windows.
>>>
>>
>> You'd probably have to just copy pythonv.exe to an appropriate
>> directory, and have it use the configuration file to find the "real"
>> prefix.  At least, that'd be a relatively obvious way to do it, and it
>> would have the advantage of being symmetrical across platforms: just
>> copy or symlink pythonv, and make sure the real prefix is in your
>> config file.
>>
>> (Windows does have "shortcuts" but I don't think that there's any way
>> for a linked program to know *which* shortcut it was launched from.)
>>
>
> No automatic way, but shortcuts can include parameters, not just the
> program name.  So a parameter could be --prefix as was suggested in another
> response, but for a different reason.
>
> Windows also has hard-links for files.
>
> A lot of Windows tools are completely ignorant of both of those linking
> concepts... resulting in disks that look to be over capacity when they are
> not, for example.


Virtualenv uses copies when it can't use symlinks.  A copy (or hard link)
seems appropriate on systems that do not have symlinks.  It would seem
reasonable that on Windows it might look in the registry to find the actual
location where Python was installed.  Or... whatever technique Windows
people think is best; it's simply necessary that the interpreter know its
location (the isolated environment) and also know where Python is installed.
 All this needs to be calculated in C, as the standard library needs to be
on the path very early (so os.symlink wouldn't help, but any C-level
function to determine this would be helpful).

(It's maybe a bit lame of me that I'm dropping this in the middle of PyCon,
as I'm not online frequently during the conference; sorry about that)

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://twitter.com/ianbicking
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100220/20ba9199/attachment.htm>


More information about the Python-Dev mailing list