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 lemburg
Recipients Arfrever, akitada, belopolsky, christian.heimes, doko, eric.araujo, ivazquez, jafo, lemburg, matejcik
Date 2009-11-06.17:27:20
SpamBayes Score 7.2164497e-16
Marked as misclassified No
Message-id <4AF45C8D.2020602@egenix.com>
In-reply-to <1257524783.55.0.781160112934.issue1294959@psf.upfronthosting.co.za>
Content
jan matejek wrote:
> 
> jan matejek <jmatejek@suse.cz> added the comment:
> 
> thanks for the info; however, it still means that python needs to learn
> to live in places other than "/usr/lib"

The main problem is that Python's configuration system is not
geared up to having the lib directories for platform dependent
and platform independent parts use different names.

It currently only supports using different path *prefixes* for
such setups (--prefix and --exec-prefix), e.g. /usr and /usr64
would work just fine. It doesn't follow --libdir.

Note that Tarek is currently working on a cleanup of the
installation schemes (see distutils/commands/install.py,
distutils/sysconfig.py and site.py) which will then also
be used by site.py to setup sys.path.

A new modules will unite all these settings, so this should
be the target of any patches regarding installation and
path lookup schemes.

BTW: The "sys.lib" setting mentioned on the tracker is not standard.
The naming also doesn't look right, since the name of the "lib"
directory path component is an OS feature, not a system one that
you configure. os.lib_dir would be more appropriate.
History
Date User Action Args
2009-11-06 17:27:22lemburgsetrecipients: + lemburg, doko, jafo, belopolsky, christian.heimes, matejcik, ivazquez, eric.araujo, Arfrever, akitada
2009-11-06 17:27:21lemburglinkissue1294959 messages
2009-11-06 17:27:20lemburgcreate