Manging multiple Python installation

[Andy Leszczynski]

Hi,
I run Mandrake 10.0 with python 2.3 installed by default. I want to keep
it as it is but need another, very customized Python installation based
of 2.3 as well. I would prefer to have it the way it is on Windows, one
folder e.g. /opt/mypython with all the stuff under that. It would be
unlike that standard installation where everything is scattered across
/usr /bin/ /.../doc. That way I can easily tar it and distribute to
whatever machine I want.

How can I achieve that? Please help, Andy

 

[Jeremy Jones]

Hi,
I run Mandrake 10.0 with python 2.3 installed by default. I want to keep
it as it is but need another, very customized Python installation based
of 2.3 as well. I would prefer to have it the way it is on Windows, one
folder e.g. /opt/mypython with all the stuff under that. It would be
unlike that standard installation where everything is scattered across
/usr /bin/ /.../doc. That way I can easily tar it and distribute to
whatever machine I want.

How can I achieve that? Please help, Andy

Download the source, untar, cd to the new directory, run:

../configure --prefix=/opt/mypython
make
make install

HTH,

JMJ

 

[Andy Leszczynski]

Andy Leszczynski wrote:

Download the source, untar, cd to the new directory, run:

./configure --prefix=/opt/mypython
make
make install

Is there any way to pass the prefix to the "make install"? Why "make"
depends on that?

A.

 

[Robert Kern]

Is there any way to pass the prefix to the "make install"?

Is passing it to the configure script a problem?

Why "make"
depends on that?

I think that parts of the configuration depend on knowing the ultimate
installation location. Specifically, you might have problems building
extension modules using distutils.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Andy Leszczynski]

Is passing it to the configure script a problem?

not really but seems to be a bit illogical to me that the build (set of
executables and libraries) depends on the destination installation path.

Under M$ Windows I was able to install Python in let's say C:\Program
Files\python and then move/copy it frelly to whatever location I need.
Only thing was the resetting PATH to the new location. I miss that under
Linux.

A.

 

[Jeremy Jones]

Jeremy Jones wrote:



Is there any way to pass the prefix to the "make install"? Why "make"
depends on that?

A.

What does it matter? If you *could* pass it to make, what does that buy
you? I'm not a make guru, but I'm not sure you can do this. Someone
else better versed in make will certainly chime in if I'm wrong. But I
think make just looks at the Makefile and does what it's going to do.
If you want different behavior, you edit the Makefile or you get the
Makefile created differently with configure.

JMJ

 

[Mike Meyer]

not really but seems to be a bit illogical to me that the build (set
of executables and libraries) depends on the destination installation
path.

It's not clear that the build depends on the destination. The
install does, though. The Makefile does the install, so it needs the
prefix. config builds the makefile, so it also needs the prefix.

Under M$ Windows I was able to install Python in let's say C:\Program
Files\python and then move/copy it frelly to whatever location I
need. Only thing was the resetting PATH to the new location. I miss
that under Linux.

Are you sure it doesn't work well enough for you to use on Linux? A
quick grep on the python binary and library files reveal that only
pydoc knows the prefix - and that points to files that don't exist on
my system. That leaves five things to worry about: unix avoids making
the user muck with the path by installing the binary in the path, so
you have to move the binaries and the libraries separately. The pydoc
executable uses the path to the python binary in it's #! line. If you
use the shared binary, you may have to muck with the load library
state information (not sure what to use to do this on your
Linux). Third party libraries may break. Oh yeah - tracebacks on .pyc
and .pyo files may be confused because the source files aren't where
they where when the file was generated, but that should be the same
as it is on Windows.

<mike

 

[Roel Schroeven]

What does it matter? If you *could* pass it to make, what does that buy
you? I'm not a make guru, but I'm not sure you can do this. Someone
else better versed in make will certainly chime in if I'm wrong. But I
think make just looks at the Makefile and does what it's going to do.
If you want different behavior, you edit the Makefile or you get the
Makefile created differently with configure.

That way you could install to a different directory without having to
rebuild the whole thing. I don't think that uses case happens very
often, but I've certainly encountered it (not in relation to Python though).

 

[Jeremy Jones]

Jeremy Jones wrote:




That way you could install to a different directory without having to
rebuild the whole thing. I don't think that uses case happens very
often, but I've certainly encountered it (not in relation to Python though).

I guess I'm still having a hard time understanding "what does it
matter?". Even if he reconfigures, he's not going to rebuild the whole
thing unless he does a make clean. For example, I just built Python
twice, once with a prefix of /usr/local/apps/pytest1 and then with a
prefix of /usr/local/apps/pytest2 and timed the compile:

BUILD 1:

jmjones@qiwi 7:16AM Python-2.4.1 % cat compile_it.sh
../configure --prefix=/usr/local/apps/pytest1
make
make install

../compile_it.sh 107.50s user 9.00s system 78% cpu 2:28.53 total



BUILD 2:

jmjones@qiwi 7:18AM Python-2.4.1 % cat compile_it.sh
../configure --prefix=/usr/local/apps/pytest2
make
make install

../compile_it.sh 21.17s user 6.21s system 56% cpu 48.323 total


I *know* a significant portion of the time of BUILD 2 was spent in
configure. So if he's really eager to save a few CPU seconds, he can
edit the Makefile manually and change the prefix section. Maybe I'm
just a slow file editor, but I would do configure again just because
it'd probably be faster for me. Not to mention potentially less error
prone. But he's going to have to build something again. Or not. He
*should* be able to just tar up the whole directory and it should "just
work". I moved /usr/local/apps/pytest1 to /usr/local/apps/pyfoo and
imported xml.dom.minidom and it worked. I'm guessing the python binary
searches relative to itself first (??). But if I move the python binary
to a new location, it doesn't find xml.dom.minidom.

JMJ

 

[Andy Leszczynski]

I guess I'm still having a hard time understanding "what does it
matter?".

I was under impression that configure embeds the prefix in the build
itself. I was concerned to have to preform the configure/make every time
I change the destination path. It turns out that the makefile produced
by configure uses prefix only for the install. Thus it is not big deal
anymore.

Thx for all commnets.

A.