-----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 [email protected] 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----- _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
