[issue6060] PYTHONHOME should be more flexible (and controllable by --libdir)

[soundmurderer]

soundmurderer  added the comment:

OK, I'm convinced.  Changing PYTHONHOME is bad.  But I am all in favor
R. David Murray's solution of extending to include something like
PYTHONHOMELIB.

Martin v. Löwis: What I want is simply to be able to use --libdir to
tell ./configure where to put standard Python libs, and I want my Python
installation to recognize this lib location without having to hack
PYTHONPATH or PYTHONHOME or anything else.

This would make the behavior of --libdir exactly what people generally
expect from using configure scripts supplied by many other projects.  As
of now, setting --libdir doesn't even do anything, silently!  But even
fixing --libdir per patch in http://bugs.python.org/issue858809 still
doesn't work because the lib path has a hardcoded component.

I just think that a sys admin, when he/she sees a configure script,
should be able to tell it what to do via flags, run it, and expect it to
Do The Right Thing, without worrying about the Python-specific
workarounds to make libs and bins go to the desired place.

--

___
Python tracker 
<http://bugs.python.org/issue6060>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue858809] Use directories from configure rather than hardcoded

[soundmurderer]

soundmurderer  added the comment:

OK done, opened a feature request for this pet peeve of mine. ;-)  Maybe
someday I'll complain about something substantial...

See: http://bugs.python.org/issue6060

--

___
Python tracker 
<http://bugs.python.org/issue858809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6060] PYTHONHOME should be more flexible (and controllable by --libdir)

[soundmurderer]

New submission from soundmurderer :

The PYTHONHOME variable does not allow complete control over making a
Python installation find its own libs because "lib/pythonX.Y" gets
appended to it, see:
http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME

For example, let's say my Python installation is here:
/home/soundmurderer/lib/x86_64/python2.6

I cannot set PYTHONHOME to point to this, because my path does not end
in "lib/pythonX.Y".  Of course, you could say that I should just move
the Python libs, but it may create inconsistencies on how stuff is
organized on some systems.  PYTHONHOME should point to the Python
installation root, period.  Please give the admin complete control.

Also, the --libdir flag to ./configure should work and set PYTHONHOME
correctly.  The fact that it does nothing has its own ticket, see:
http://bugs.python.org/issue858809

It is, however, my humble opinion that fixing that other ticket properly
also necessitates fixing how PYTHONHOME works (because --libdir should
set the default PYTHONHOME during build/install), so they should really
be one issue.

Thanks!

--
components: Build, Installation
messages: 88066
nosy: soundmurderer
severity: normal
status: open
title: PYTHONHOME should be more flexible (and controllable by --libdir)
type: feature request
versions: Python 2.5, Python 2.6

___
Python tracker 
<http://bugs.python.org/issue6060>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue858809] Use directories from configure rather than hardcoded

[soundmurderer]

soundmurderer  added the comment:

OK, I am now convinced that even with this patch, the Python build
process still won't work correctly because --libdir (post-patch) will
not correctly set the default PYTHONHOME.  Moreover, the very way that
PYTHONHOME gets used needs to change.  PYTHONHOME specifies "prefix"
and/or "exec_prefix", but the problem is that to find the lib dir,
Python tacks "lib/pythonX.X" onto the ends of these paths!  More info here:

http://docs.python.org/using/unix.html#python-related-paths-and-files
http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME

So, even with this patch, I still can't install, for example, to:
/home/soundmurderer/lib/x86_64/python2.6

I am forced to install to a location that ends with "lib/python2.6", e.g.:

/home/soundmurderer/x86_64/lib/python2.6

or else hack some stuff together with symlinks to make PYTHONHOME go to
the right place.

This seems to be a problem more fundamental than just incomplete
"./configure" in the build process and I think it warrants another
ticket, which I'm about to open.

Now, in regards to --libdir, even though the patch makes the
installation put the files in the expected location, Python will
probably not find it.

--

___
Python tracker 
<http://bugs.python.org/issue858809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue858809] Use directories from configure rather than hardcoded

[soundmurderer]

soundmurderer  added the comment:

I tried applying nijel's 2.3.2 patch to Python 2.6.2 Makefile.pre.in,
then configure/make/install with --bindir and --libdir flags to
./configure.  It works in terms of producing the correct Makefile with
LIBDIR and BINDIR that I want, but I get problems after the "make
install" step when I launch the Python interpreter.  This is what happens:

Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
'import site' failed; use -v for traceback
Python 2.6.2 (r262:71600, May 15 2009, 22:46:19)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

I can work around bad imports and "could not find libraries" by adding
various subdirs of my desired LIBDIR to PYTHONHOME and PYTHONPATH.  But
the point is -- I thought that a *properly* installed Python
distribution should know where to find its own standard libraries??  I
should not have to hack PYTHONHOME and PYTHONPATH to get my local
install to work... right?

Once upon a time in 2.5.x days, I was able to do a local install using
only ./configure --prefix, and that's it.  No hacking PYTHONHOME or
PYTHONPATH that I recall.

How is the path to stuff like site.py getting encoded in the Python
installation?  Because I suspect that although nijel's patch may work
for generating makefiles that put binaries/libs in the right place, that
encoding step is still getting botched, requiring to manually set
PYTHONHOME and PYTHONPATH as a workaround.

Or maybe I am just confused.

--

___
Python tracker 
<http://bugs.python.org/issue858809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue858809] Use directories from configure rather than hardcoded

[soundmurderer]

soundmurderer  added the comment:

I can confirm that --bindir and --libdir are broken in Python 2.6.2,
despite the fact that ./configure --help lists them as helpful options.
 At the very least, ./configure should complain if you're using options
that don't do anything!  That would be the easy fix.

Here is what I am doing:

./configure \
--prefix=/home/soundmurderer \
--bindir=/home/soundmurderer/bin/x86_64/Python-2.6.2 \
--libdir=/home/soundmurderer/lib/x86_64 

OK, now let's see the relevant section of the generated Makefile:

# Install prefix for architecture-independent files
prefix= /home/soundmurderer/auzilov

# Install prefix for architecture-dependent files
exec_prefix=${prefix}

# Install prefix for data files
datarootdir=${prefix}/share

# Expanded directories
BINDIR= $(exec_prefix)/bin
LIBDIR= $(exec_prefix)/lib
MANDIR= ${datarootdir}/man
INCLUDEDIR= ${prefix}/include
CONFINCLUDEDIR= $(exec_prefix)/include
SCRIPTDIR=  $(prefix)/lib

# Detailed destination directories
BINLIBDEST= $(LIBDIR)/python$(VERSION)
LIBDEST=$(SCRIPTDIR)/python$(VERSION)
INCLUDEPY=  $(INCLUDEDIR)/python$(VERSION)
CONFINCLUDEPY=  $(CONFINCLUDEDIR)/python$(VERSION)
LIBP=   $(LIBDIR)/python$(VERSION)

So, the --libdir and --bindir flags had no effect on LIBDIR and BINDIR,
and I wind up editing the Makefile by hand to get desired behavior.

------
nosy: +soundmurderer

___
Python tracker 
<http://bugs.python.org/issue858809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com