This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients eric.araujo, lemburg, mishikal, r.david.murray, vinay.sajip
Date 2013-12-13.19:26:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1386962818.77.0.120918695898.issue19968@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2013-12-13 19:26:58r.david.murraysetrecipients: + r.david.murray, lemburg, vinay.sajip, eric.araujo, mishikal
2013-12-13 19:26:58r.david.murraysetmessageid: <1386962818.77.0.120918695898.issue19968@psf.upfronthosting.co.za>
2013-12-13 19:26:58r.david.murraylinkissue19968 messages
2013-12-13 19:26:58r.david.murraycreate