[Distutils] pythonv, take two

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/18/2011 08:01 PM, Vinay Sajip wrote:
> Hi Carl,
> 
>> So, possibilities I see for addressing this:
>>
>> 1. Decide that in real cases of real Python installations, it's so
>> unlikely to happen that we won't worry about it. I think it's possible
>> that this is acceptable; the biggest practical problem is likely to be
>> people trying to test this out during PEP review from a not-installed
>> checkout, just like you did. We'd have to be careful to instruct people
>> that it doesn't work that way, and might also want to add a check in the
>> env-creation script to verify that the created env works properly, and
>> if it doesn't give them some clue why not.
> 
> Yes, I think this is important to do, or at least to have -v output show which
> stdlib is being used.
> 
>> 2. Decide that we just don't support copied binaries, only symlinked
>> ones. Apparently (I am Windows-ignorant) recent Windows versions do
>> support symlinks? So this might only involve dropping support for old
>> Windows'? How important is it for a new feature like this to fully
>> support all operating systems that Python supports? We could also not
>> expose the copy-binary option to the user, but fall back to it if we
>> have no symlinks; which ends up being option (1) but trying to narrow
>> even more the potential breakage cases.
> 
> Well, Windows XP is still pretty common and likely to remain so for some time.
> On Windows XP, symlinks don't work, but confusingly os.symlink exists on recent
> Pythons (certainly 3.2). I had to make a patch in my virtualenv fork to handle
> this in copyfile: on XP, os.symlink raises NotImplementedError because the
> underlying Windows API function is missing.
> 
> So, even if it's just for Windows, I think copying will need to be supported,
> but perhaps only from Pythons whose sys.prefix is correctly set.
> 
>> 3. The fully-reliable fix would be to somehow give the copied binary a
>> hint where to find the right standard library, and this would involve
>> adding something to the algorithm in getpath.c. The hint could take the
>> form of a key in the config file, but I'd really like to avoid fully
>> parsing the config-file in C and then again in Python later on. The hint
>> could also be some kind of specially-formatted comment line at the top
>> of the config file, which would require less C code to find and parse?
>>
>> Any thoughts on this (or alternative solutions I haven't thought of) are
>> most welcome.
> 
> I know that ConfigParser format files are the first thing one thinks of, but
> perhaps a simpler C-parseable format deserves further consideration.

One possibility is to make the config file format just a sequence of
long-form command-line options, one per line, with the leading '--'
stripped.  This option would involve inventing a '--use-prefix' option
(bikeshedders, start your sprayguns ;), but would make parsing it a
mostly trivial exercise.


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2D9bgACgkQ+gerLs4ltQ7VwwCfQku+E1AnGzAYTG6blRgiq6IF
n8MAoMGYbjS/E8+2l2LsvhYO2BhLGtEb
=mA1G
-----END PGP SIGNATURE-----