[Distutils] reservations about pythonv

[Barry Warsaw]

On Mar 16, 2011, at 07:19 PM, Carl Meyer wrote:

>This alternative approach (with a symlink and config file) sounds pretty good
>to me as well after our discussion at the sprints. The downsides I see:
>
>1. Cross-platform inconsistency. Windows virtualenvs would be isolated from
>system python binary upgrades, *nix would not (some, like Brandon, consider
>this isolation a feature, so maybe *nix should allow that option too?) On the
>whole this doesn't seem like a big issue.

Agreed.  Windows users are used to doing Python upgrades themselves since
their operating system doesn't help them.  So if they have to copy binaries,
they'll have to be aware that when they upgrade Python, their virtualenvs
won't get automatically updated.

For *nix users, I agree that it might be a useful option to either copy
binaries or use a symlink, though I think the later should be the default.

>2. There would be no way to set LD_LIBRARY_PATH to include the virtualenv
>prior to execution of python. To be honest, I don't understand why this is
>needed, as current virtualenv doesn't do it and I haven't seen it break
>anything (compiled modules work fine in a venv). But people with more
>experience seemed to think it was needed at our open space discussion last
>Saturday. Perhaps someone can clarify what specifically breaks without this?

I was thinking about this too.  I'm trying to recall a similar situation I had
in a long-previous job where we had to re-exec to pick up $LD_LIBRARY_PATH (on
Solaris IIRC).  The issue there was that the Python binary *itself* needed
$LD_LIBRARY_PATH set before it could find some shared libraries, so that envar
had to essentially be set before `python` could run.

We've got a different situation here though.  We're assuming `python` itself
runs just fine, but that some shared library in the virtualenv is needed to
import an extension module.  So, why doesn't Python set $LD_LIBRARY_PATH in
its own environment once it knows its running in a virtualenv?  That way, any
subsequent searches for shared libraries would find them in the virtualenv.

OTOH, I vaguely recall that while this *should* work, it actually doesn't
because once the executable has started, $LD_LIBRARY_PATH isn't consulted
again.

The above just means my memory is too faulty to of much use ;).  I'll just
echo Carl's request for specific cases where $LD_LIBRARY_PATH needs to be set.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20110316/5880f1e3/attachment-0001.pgp>