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 BinaryKhaos
Recipients BinaryKhaos, pitrou, vinay.sajip
Date 2014-04-11.13:15:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1397222157.5.0.0994845445885.issue21197@psf.upfronthosting.co.za>
In-reply-to
Content
The problem is: Some Linux dists install Python under /usr/lib64 on a multilib systems and patch Python accordingly, e.g. Gentoo or Fedora. Thus, Python looks for lib64/pythonX.Y/... which is also why pip installs to lib64/... by default on those systems.

This has no effect on Windows systems btw.

virtualenv introduced the symlink sometime 2007, if I researched that correctly (https://github.com/pypa/virtualenv/commit/244b23b5e89b58a4c2777a0f0975bbab7fda4dd2) and kept and tuned it ever since.

Again, it is debatable where this should be fixed but since it is such an easy fix to venv while potentially keeping compatibility with tools relying on finding everything under lib/... as well as virtualenv itself, I'd think it would be nice to have it here.

@vinay.sajip: I never said anything about adding links to the site-packages itself-- even though those can be useful and safe in a very limited number of cases. It is just about the fact that on systems where Python is installed under lib64, pip also installs to lib64 while the venv only creates a lib/ dir, no lib64/ symlink to it and some tools (rightfully so) rely on finding everything under lib/ itself... which is empty in that case. For the global python that is irrelevant because there is always a lib to lib64 symlink on multilib systems.
History
Date User Action Args
2014-04-11 13:15:57BinaryKhaossetrecipients: + BinaryKhaos, vinay.sajip, pitrou
2014-04-11 13:15:57BinaryKhaossetmessageid: <1397222157.5.0.0994845445885.issue21197@psf.upfronthosting.co.za>
2014-04-11 13:15:57BinaryKhaoslinkissue21197 messages
2014-04-11 13:15:55BinaryKhaoscreate