Windows install to custom location after building from source

[dan.erik.petersen]

Hi all -

I have succeeded in building Python 2.6.1 from source under Windows XP
by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
both from the Visual C++ application as well as from the commandline
using :

vcbuild pcbuild.sln 'Release|Win32'

This builds fine (allowing for errors in the build of modules like
sql3 and the like where I have not fetched source code), and creates
its products "in-place" in the source directory.

My question/desire is :

I would like to move this Python installation in a clean manner over
to another location outside the unpackaged source directory (e.g. from
C:\Python-2.6.1 to C:\custom_path\python). Is there already some
automatic command that can perform this? If not, which files do I move
where and what should the structure be? How do ensure all the Python
code related to the install is byte-compiled and ready for use?

I have Googled as best as I can but no luck.

Thanks,

Dan

 

[dan.erik.petersen]

I suppose that what I am looking for is the Windows version of "make
install" as we know it after running configure with --
prefix=custom_location --exec-prefix=custom_location flags and make on
the Linux platform.

Dan

 

[Gabriel Genellina]

I have succeeded in building Python 2.6.1 from source under Windows XP
by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
both from the Visual C++ application as well as from the commandline
[...]
I would like to move this Python installation in a clean manner over
to another location outside the unpackaged source directory (e.g. from
C:\Python-2.6.1 to C:\custom_path\python). Is there already some
automatic command that can perform this? If not, which files do I move
where and what should the structure be? How do ensure all the Python
code related to the install is byte-compiled and ready for use?

Create an installer (pythonXXX.msi) and use it to install wherever you
want. See Tools\msi in the source tree.

If you built using VS2008 Express Edition, probably don't have cabarc.exe
- download it from http://support.microsoft.com/kb/310618/en-us and make
sure the bin directory is in your PATH before running msi.py

 

[dan.erik.petersen]

The Windows build system doesn't have anything related to "make
install". You have to assemble a distribution yourself or you have to
create a MSI package. See Tools/msi/

Christian

Thanks guys -

Looks like I'll have to settle on building a distribution myself, as a
solution based on MSI isn't in the cards ... so far, so good.

Dan;

 

[Tim Golden]

I have succeeded in building Python 2.6.1 from source under Windows XP
by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
both from the Visual C++ application as well as from the commandline
[...]
I would like to move this Python installation in a clean manner over
to another location outside the unpackaged source directory (e.g. from
C:\Python-2.6.1 to C:\custom_path\python). Is there already some
automatic command that can perform this? If not, which files do I move
where and what should the structure be? How do ensure all the Python
code related to the install is byte-compiled and ready for use?

Create an installer (pythonXXX.msi) and use it to install wherever you
want. See Tools\msi in the source tree.

If you built using VS2008 Express Edition, probably don't have
cabarc.exe - download it from
http://support.microsoft.com/kb/310618/en-us and make sure the bin
directory is in your PATH before running msi.py

A small caveat here: I've just done this myself and I had to
patch one or two things very slightly. I have the htmlhelp
libraries in a non-standard place and the make.bat helper
file in the doc\ directory hardcodes its location. The
patch from this tracker issue:

http://bugs.python.org/issue2421

solves that (with the help of an env var).

The other thing is that the instructions in the pcbuild/readme.txt
and the corresponding code in Tools\buildbot\external-common.bat
export the external tcl/tk libraries under the name tcl-8* and tk-8*
whereas the msi.py code is expecting to find them under tcl8*
and tk8*. In addition, msi.py is looking for a tix-* directory
which doesn't seem to come from anywhere.

I don't know if that constitutes a bug in msi.py or one in
the pcbuild / external-common.bat or neither of the two.
Happy to produce a patch if needed.

In addition, the CVS version of pywin32 which I built in
order to run the msi.py script has a small bug in genpy
which prevents it from generating COM support in the way
in which msi.py does it. I've reported it as issue 2672514
on the pywin32 tracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=2672514&group_id=78018&atid=551954

Anyhow, at the end I have a working Python 2.7a0 running
under Windows.

TJG

 

[Martin v. Löwis]

In addition, the CVS version of pywin32 which I built in

order to run the msi.py script has a small bug in genpy
which prevents it from generating COM support in the way
in which msi.py does it.

I'm using Python 2.4 to run msi.py; that has always worked
fine for me.

Regards,
Martin

P.S. Don't forget to run merge.py after msi.py

 

[Martin v. Löwis]

Do you mean 3.1a0? As far as I know, 2.7a0 requires the use

of the time machine, as it is expected to be 3 months out.

The current trunk calls itself 2.7a0. I think you might be referring
to 3.0a1.

Regards,
Martin

 

[Tim Golden]

I'm using Python 2.4 to run msi.py; that has always worked
fine for me.

Interesting. Didn't even think of that. Well, it works ok
with my micro-patches anyway.

Regards,
Martin

P.S. Don't forget to run merge.py after msi.py

What does the merge do? I can't find mention of it
in the docs.

Thanks for the input, by the way.

TJG

 

[Tim Golden]

Do you mean 3.1a0? As far as I know, 2.7a0 requires the use
of the time machine, as it is expected to be 3 months out.

No; 2.7a0 is the version number of the svn HEAD.

If you do get an installer built, even having a semi-official copy
around for those of us not on the MS compiler upgrade train to
do a little alpha (and/or beta) testing as well.

There used to be nightly .msi builds, don't remember where;
if Martin (or someone) doesn't chip in with something, I'll
happily provide an unofficial build. In fact, I might do it
anyway if I can get my act together.

TJG

 

[Martin v. Löwis]

What does the merge do? I can't find mention of it

in the docs.

It merges the msvcrt merge module into the installer (and then
monkey patches it, to revert the msm decision of setting
ALLUSERS). I tried to integrate it originally as a step
after creating the msi. Unfortunately, the merge object refused
to open the database, claiming that the file is in use (even
though I had closed it). Hence I need to processes. If you
can figure out how to combine them into one, again, that
would be much appreciated.

If you don't merge the CRT, the resulting Python installation
will fail on systems were
a) VS 2008 is not installed (nor has the stand-alone CRT installer
been run, nor has anything else been installed that comes
with the CRT), and
b) Python is installed "for all users" (else a private copy of
msvcr90.dll gets installed)

Regards,
Martin

 

[Tim Golden]

It merges the msvcrt merge module into the installer (and then
monkey patches it, to revert the msm decision of setting
ALLUSERS). I tried to integrate it originally as a step
after creating the msi. Unfortunately, the merge object refused
to open the database, claiming that the file is in use (even
though I had closed it). Hence I need to processes. If you
can figure out how to combine them into one, again, that
would be much appreciated.

At the moment, I'm struggling to make it work at all

First, it relies on config.py whose existence msi.py
optionally ignores. I've created a dummy, based on the
settings in msi.py. Then I get a COM error, reproduced
below. I've got to go and do something else at the moment
but I'll look into it afterwards. I'll dump the traceback
here in case it rings any bells.

TJG

<dump>
Opened Log
Traceback (most recent call last):
File "merge.py", line 79, in <module>
merge(msi, "SharedCRT", "TARGETDIR", modules)
File "merge.py", line 27, in merge
m.OpenDatabase(msi)
File "<COMObject Msm.Merge2.1>", line 2, in OpenDatabase
pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, None, None, None, 0, -2147024786), None)
[33419 refs]

</dump>

TJG

 

[Gabriel Genellina]

It merges the msvcrt merge module into the installer (and then
monkey patches it, to revert the msm decision of setting
ALLUSERS). I tried to integrate it originally as a step

merge.py attempts to import config.py but I can't find it...

 

[Krishnakant]

hello all, Sorry for the frustrated mail.

This is my last attempt to search for a nice python library for creating
open document spreadsheet.

I tryed python-ooolib but did not find a few features like merging cells
(may be I am missing out some thing stupid ).

I have asked for some help before on this topic but seems there is no
such library in python.

Pritty strange that python can't do this much.

So please tell me if any one knows of a good solution for my problem
else I am forced to give up python for my task.

happy hacking/
Krishnakant.

 

[Martin v. Löwis]

First, it relies on config.py whose existence msi.py

optionally ignores.

Feel free to create a patch for that.

File "<COMObject Msm.Merge2.1>", line 2, in OpenDatabase
pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, None,
None, None, 0, -2147024786), None)

This is 0x8007006e; 0x6E, in turn, might be ERROR_OPEN_FAILED.
Did you pass the file name of the MSI file? If not, it computed
one, and may have done so incorrectly.

Regards,
Martin

 

[Martin v. Löwis]

merge.py attempts to import config.py but I can't find it...

Just create an empty one.

Martin

 

[Martin v. Löwis]

merge.py attempts to import config.py but I can't find it...

Just create an empty one.

Martin

 

[JanC]

This is my last attempt to search for a nice python library for creating
open document spreadsheet.

I tryed python-ooolib but did not find a few features like merging cells
(may be I am missing out some thing stupid ).

You could add that feature to python-ooolib.

I have asked for some help before on this topic but seems there is no
such library in python.

Pritty strange that python can't do this much.

"Python" can do it. (Maybe nobody using & programming the libraries that
you tried ever needed it, so they didn't implement it, but that's something
different.)

So please tell me if any one knows of a good solution for my problem
else I am forced to give up python for my task.

You could use python-uno (it's included with OOo by default, and should be
able to do everything OOo can do.)

 

[Tim Golden]

Just create an empty one.

Won't quite work: merge tries to find full_current_version
which is determined (if None) in msi.py from the rather
involved current version stuff.

I'm going to give up on this for tonight, but one possibility
is to turn msi.py into an importable module and for msilib
to import it and pull the config values from there.

TJG

 

[Martin v. Löwis]

Just create an empty one.

Won't quite work: merge tries to find full_current_version
which is determined (if None) in msi.py from the rather
involved current version stuff.

Only if you don't pass an msi file on the command line. So
I recommend that you do that.

I'm going to give up on this for tonight, but one possibility
is to turn msi.py into an importable module and for msilib
to import it and pull the config values from there.

Please, no. The only way I could accept that if merge.py would
be run at the end of msi.py (i.e. merge.py disappears).

Regards,
Martin

 

[Terry Reedy]

You could add that feature to python-ooolib.

I have answered once or twice but got no reply from you.