[issue19968] Python does not play well with 'stow'.

[R. David Murray]

R. David Murray added the comment:

Since it appears to be a perl based, it is not too surprising it works well with perl :)

A little googling turns up someone suggesting that the logic for finding things be changed slightly, such that if the binary is itself a symbolic link, it will look in the home dir of the symbolic link to see if it looks like a "python installation" where it can find things.  This *might* be a reasonable idea, but I'd prefer if the people who have worked this stuff out in the context of virtual environments were to consider this use case and make suggestions, so I've added Vinay to nosy.

It isn't a build or even an install issue, though, it's a runtime issue.  I've changed the title to reflect the real issue: python not playing well with stow's symlink setup.

I've marked this as an enhancement for 3.5, since it seems to me like a significant change in behavior, but it could be that an argument could be made that this is actually a bug, given that it seems like most unix programs work fine under such a symlink setup.

You can work around it by using a .pth file to add the site-packages dir you want onto the path, by the way, though you'd have to add that to each install by yourself.

----------
components: +Interpreter Core -Build
nosy: +vinay.sajip
title: Using DESTDIR breaks sys.path -> Python does not play well with 'stow'.
type:  -> enhancement
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________