[Distutils] pythonv, take two

Vinay Sajip vinay_sajip at yahoo.co.uk
Sat Mar 19 01:01:48 CET 2011


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.

Regards,

Vinay Sajip




More information about the Distutils-SIG mailing list