FAQ
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

Search Discussions

  • Dan Erik Petersen at Mar 6, 2009 at 8:59 am
    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
  • Christian Heimes at Mar 6, 2009 at 10:21 am

    dan.erik.petersen at gmail.com schrieb:
    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.
    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
  • Dan Erik Petersen at Mar 6, 2009 at 11:50 am

    On Mar 6, 11:21?am, Christian Heimes wrote:
    dan.erik.peter... at gmail.com schrieb:
    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.
    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;
  • Gabriel Genellina at Mar 6, 2009 at 10:32 am

    En Fri, 06 Mar 2009 06:52:00 -0200, <dan.erik.petersen at gmail.com> escribi?:

    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

    --
    Gabriel Genellina
  • Tim Golden at Mar 8, 2009 at 5:48 pm

    Gabriel Genellina wrote:
    En Fri, 06 Mar 2009 06:52:00 -0200, <dan.erik.petersen at gmail.com> escribi?:
    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Þtail&aid&72514&group_idx018&atidU1954

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

    TJG
  • Scott David Daniels at Mar 8, 2009 at 7:47 pm

    Tim Golden wrote:
    ... Anyhow, at the end I have a working Python 2.7a0 running
    under Windows.
    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.

    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.

    --Scott David Daniels
    Scott.Daniels at Acm.Org
  • Martin v. Löwis at Mar 8, 2009 at 7:51 pm

    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 at Mar 8, 2009 at 7:58 pm

    Scott David Daniels wrote:
    Tim Golden wrote:
    ... Anyhow, at the end I have a working Python 2.7a0 running
    under Windows.
    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
  • Tim Golden at Mar 10, 2009 at 9:03 pm

    Scott David Daniels wrote:
    Tim Golden wrote:
    ... Anyhow, at the end I have a working Python 2.7a0 running
    under Windows.
    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.

    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.
    I've uploaded a couple of installers here:

    http://timgolden.me.uk/python/downloads/snapshots/

    Currently, there's the Python Subversion trunk (py2.7) and the
    corresponding pywin32, built from the latest CVS. I believe
    I've got everything in there, altho' the platform test was
    failing irreproducibly when I last looked.

    I'm building the py3k branch now, so if there are no problems
    I'll upload that later tonight.

    Please take them for a spin and let me know if they work.

    TJG
  • Scott David Daniels at Mar 12, 2009 at 5:58 pm

    Tim Golden wrote:
    Scott David Daniels wrote:
    Tim Golden wrote:
    ... Anyhow, at the end I have a working Python 2.7a0 running
    under Windows.
    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.

    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.
    I've uploaded a couple of installers here:

    http://timgolden.me.uk/python/downloads/snapshots/

    Currently, there's the Python Subversion trunk (py2.7) and the
    corresponding pywin32, built from the latest CVS. I believe
    I've got everything in there, altho' the platform test was
    failing irreproducibly when I last looked.
    Thanks so much for these. Yes, they work (and I'm happily running
    little experiments).

    --Scott David Daniels
    Scott.Daniels at Acm.Org
  • Tim Golden at Mar 12, 2009 at 10:21 pm

    Scott David Daniels wrote:
    Tim Golden wrote:
    Scott David Daniels wrote:
    Tim Golden wrote:
    ... Anyhow, at the end I have a working Python 2.7a0 running
    under Windows.
    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.

    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.
    I've uploaded a couple of installers here:

    http://timgolden.me.uk/python/downloads/snapshots/

    Currently, there's the Python Subversion trunk (py2.7) and the
    corresponding pywin32, built from the latest CVS. I believe
    I've got everything in there, altho' the platform test was
    failing irreproducibly when I last looked.
    Thanks so much for these. Yes, they work (and I'm happily running
    little experiments).
    Thanks for the feedback. I'm close to building the 3.1 release, too.
    Just a few teething troubles.

    TJG
  • Martin v. Löwis at Mar 8, 2009 at 7:51 pm

    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
  • Tim Golden at Mar 8, 2009 at 7:58 pm

    Martin v. L?wis wrote:
    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.
    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
  • Martin v. Löwis at Mar 8, 2009 at 8:08 pm

    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 at Mar 8, 2009 at 8:43 pm

    Martin v. L?wis wrote:
    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.

    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
  • Krishnakant at Mar 8, 2009 at 8:59 pm
    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.
  • JanC at Mar 8, 2009 at 10:02 pm

    Krishnakant wrote:

    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.)


    --
    JanC
  • Terry Reedy at Mar 9, 2009 at 2:05 am

    JanC wrote:
    Krishnakant wrote:
    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.
    I have answered once or twice but got no reply from you.
  • Krishnakant at Mar 9, 2009 at 7:40 am
    Hi Terry,

    Well, You did reply i know, but seems i lost that mail some where,
    My mail client must have messed up the mail.

    any ways thanks for your reply,
    Right now I am stuck very badly.

    The problem is that I am trying python-ooolib and did find the library
    pritty good.
    But the problem is that library is missing a major feature from my
    requirement context.
    I need to merge cells in a spreadsheet and this library won't do that.

    Do you know how I can work around this?

    I tryed searching for py2odf but did ont find any results.

    Do you want me to continue on the previous thread (I will try and dig
    that out ).


    happy hacking.
    Krishnakant.
  • Terry Reedy at Mar 9, 2009 at 7:55 pm

    Krishnakant wrote:
    Hi Terry,

    Well, You did reply i know, but seems i lost that mail some where,
    My mail client must have messed up the mail.

    any ways thanks for your reply,
    Right now I am stuck very badly.

    The problem is that I am trying python-ooolib and did find the library
    pritty good.
    But the problem is that library is missing a major feature from my
    requirement context.
    I need to merge cells in a spreadsheet and this library won't do that.
    I think you are confusing process and result. The result is a cell that
    spans more than one column or row *when displayed*, thus hiding the
    cells that would otherwise be displayed. This is, I am 99.9% sure,
    controlled by an attribute of the visually expanded cell.

    In OOCalc, the process is to mark a block of cells and select Format /
    Merge Cells. But still, the result will be a change in the upper left
    attribute. Thus I suggested you make a .ods file with expanded cells
    and then read the xml to see what cell element attribute is set thereby.
    Any decent odf library will be able to set element attributes.

    If the about-to-be hidden cells are not empty, OOCcalc gives you the
    option of converting all cell contents to strings and joining them into
    one string in the expanded cell. If you create .ods from scratch, you
    should never need to do this. If you edit an existing .ods, something like
    ' '.join(str(cell.contents for cell in merge_group))
    possibly in a function that also sets the attribute, should be easy
    enough to write. And, of course, you will be able to do things other
    than the one option OOCalc gives you.

    In other words, I do not think you *need* an existing cell-merge function.
    Do you know how I can work around this?
    See above.
    I tryed searching for py2odf but did ont find any results.
    Whoops. odfpy at
    http://opendocumentfellowship.com/development/projects/odfpy

    but I strongly suspect you can do what you want with python-ooolib.

    Terry Jan Reedy
  • Krishnakant at Mar 10, 2009 at 8:04 am

    On Mon, 2009-03-09 at 15:55 -0400, Terry Reedy wrote:
    I think you are confusing process and result. The result is a cell that
    spans more than one column or row *when displayed*, thus hiding the
    cells that would otherwise be displayed. This is, I am 99.9% sure,
    controlled by an attribute of the visually expanded cell.
    That might be the case imho, But I tried increasing the width of the
    column using python-ooolib and i could not get the effect of a merged
    cells.

    I am now trying odfpy and hope it will do what I want.

    In OOCalc, the process is to mark a block of cells and select Format /
    Merge Cells. But still, the result will be a change in the upper left
    attribute. Thus I suggested you make a .ods file with expanded cells
    and then read the xml to see what cell element attribute is set thereby.
    Any decent odf library will be able to set element attributes.
    What did you mean by the upper left attribute, are you asuming that the merged cells are in the top row? In my case that's actually the case beacuse because I want my python script to generate an ods file with the cells in the top row merged from let's say a1 to d1.
    Talking about the xml, which file should I look at to see the effect of
    merging cells?



    If the about-to-be hidden cells are not empty, OOCcalc gives you the
    option of converting all cell contents to strings and joining them into
    one string in the expanded cell. If you create .ods from scratch, you
    should never need to do this. If you edit an existing .ods, something like
    ' '.join(str(cell.contents for cell in merge_group))
    possibly in a function that also sets the attribute, should be easy
    enough to write. And, of course, you will be able to do things other
    than the one option OOCalc gives you.
    This is exactly what I was trying to achieve with the python-ooolib
    module but could not do it.
    The library did have a cet_cell_property function but did not allow for
    merging.
    In other words, I do not think you *need* an existing cell-merge function.
    But the library I use does not allow me to try the method you suggested.
    Seems that I will have to look at the xml and write my own module.
    Do you know how I can work around this?
    See above.
    I tryed searching for py2odf but did ont find any results.
    Whoops. odfpy at
    http://opendocumentfellowship.com/development/projects/odfpy

    but I strongly suspect you can do what you want with python-ooolib.
    No buddy, I tryed with ooolib but now given up unless some one points
    out what I am missing.
    happy hacking.
    Krishnakant.
  • John Machin at Mar 9, 2009 at 9:58 pm

    On Mar 10, 6:55?am, Terry Reedy wrote:
    Krishnakant wrote:
    I need to merge cells in a spreadsheet and this library won't do that.
    I think you are confusing process and result. ?The result is a cell that
    spans more than one column or row *when displayed*, thus hiding the
    cells that would otherwise be displayed. This is, I am 99.9% sure,
    controlled by an attribute of the visually expanded cell.

    In OOCalc, the process is to mark a block of cells and select Format /
    Merge Cells. ?But still, the result will be a change in the upper left
    attribute. ?Thus I suggested you make a .ods file with expanded cells
    and then read the xml to see what cell element attribute is set thereby.
    Any decent odf library will be able to set element attributes.
    It doesn't appear to be quite so simple.

    ODS uses a <table:table-cell> element as usual for the upper left
    cell. Attributes set the range e.g. table:number-columns-spanned="3"
    table:number-rows-spanned="2"

    The gotcha is that it uses a *different* element for the cells covered
    by the range. Example:
    <table:covered-table-cell table:number-columns-repeated="2" />

    This is looks like structural amendments are needed to a package like
    (python-)?ooolib(-python)? that doesn't grok merged cells -- its
    source doesn't contain the string "covered". Doesn't seem like it
    could be done just by poking in attributes.

    Here's an example of 2 merged ranges: A1:C2 contains the text "foo"
    and D1:D2 contains "bar"

    <table:table-row table:style-name="ro1">
    - <table:table-cell table:style-name="ce1" office:value-type="string"
    table:number-columns-spanned="3" table:number-rows-spanned="2">
    <text:p>foo</text:p>
    </table:table-cell>
    <table:covered-table-cell table:number-columns-repeated="2" />
    - <table:table-cell table:style-name="ce1" office:value-type="string"
    table:number-columns-spanned="1" table:number-rows-spanned="2">
    <text:p>bar</text:p>
    </table:table-cell>
    </table:table-row>
    - <table:table-row table:style-name="ro1">
    <table:covered-table-cell table:number-columns-repeated="4" />
    </table:table-row>

    Aside: If you are wondering where the cell addresses (D1 etc) are,
    they're in the reader's current_row and current_col variables :-)
    Perhaps this was intended to save space, but what of table:number-
    columns-repeated="4" ??

    Cheers,
    John
  • Terry Reedy at Mar 10, 2009 at 4:27 am

    John Machin wrote:
    On Mar 10, 6:55 am, Terry Reedy wrote:
    Krishnakant wrote:
    I need to merge cells in a spreadsheet and this library won't do that.
    I think you are confusing process and result. The result is a cell that
    spans more than one column or row *when displayed*, thus hiding the
    cells that would otherwise be displayed. This is, I am 99.9% sure,
    controlled by an attribute of the visually expanded cell.

    In OOCalc, the process is to mark a block of cells and select Format /
    Merge Cells. But still, the result will be a change in the upper left
    attribute. Thus I suggested you make a .ods file with expanded cells
    and then read the xml to see what cell element attribute is set thereby.
    Any decent odf library will be able to set element attributes.
    It doesn't appear to be quite so simple.

    ODS uses a <table:table-cell> element as usual for the upper left
    cell. Attributes set the range e.g. table:number-columns-spanned="3"
    table:number-rows-spanned="2"

    The gotcha is that it uses a *different* element for the cells covered
    by the range. Example:
    <table:covered-table-cell table:number-columns-repeated="2" />

    This is looks like structural amendments are needed to a package like
    (python-)?ooolib(-python)? that doesn't grok merged cells -- its
    source doesn't contain the string "covered". Doesn't seem like it
    could be done just by poking in attributes.
    I guess it makes some sense that a cell that gets covered should be
    changed to a covered-cell rather than merely being marked as 'covered'
    or the covering left implicit by position. This would make it easier
    for display software.

    In any case, api-for-odfpy.odt has

    5.17.12 table.CoveredTableCell
    Requires the following attributes: No attribute is required.
    Allows the following attributes: booleanvalue, contentvalidationname,
    currency, datevalue, formula, numbercolumnsrepeated, protect,
    stringvalue, stylename, timevalue, value, valuetype.
    These elements contain table.CoveredTableCell: table.TableRow.
    The following elements occur in table.CoveredTableCell: dr3d.Scene,
    draw.A, draw.Caption, ...

    so odfpy, at least, can create such elements.
    Here's an example of 2 merged ranges: A1:C2 contains the text "foo"
    and D1:D2 contains "bar"

    <table:table-row table:style-name="ro1">
    - <table:table-cell table:style-name="ce1" office:value-type="string"
    table:number-columns-spanned="3" table:number-rows-spanned="2">
    <text:p>foo</text:p>
    </table:table-cell>
    <table:covered-table-cell table:number-columns-repeated="2" />
    - <table:table-cell table:style-name="ce1" office:value-type="string"
    table:number-columns-spanned="1" table:number-rows-spanned="2">
    <text:p>bar</text:p>
    </table:table-cell>
    </table:table-row>
    - <table:table-row table:style-name="ro1">
    <table:covered-table-cell table:number-columns-repeated="4" />
    </table:table-row>

    Aside: If you are wondering where the cell addresses (D1 etc) are,
    they're in the reader's current_row and current_col variables :-)
    Perhaps this was intended to save space, but what of table:number-
    columns-repeated="4" ??
    Those are the 4 cell covered in the second row -- 3 by 'foo' and 1 by
    'bar'. I believe there could have been two separate entries, but this
    is more compact, if less clear ;-)

    Terry Jan Reedy
  • Krishnakant at Mar 10, 2009 at 8:26 am

    On Tue, 2009-03-10 at 00:27 -0400, Terry Reedy wrote:

    In any case, api-for-odfpy.odt has
    I am going through the documentation for odfpy but finding it pritty
    complex right now.
    5.17.12 table.CoveredTableCell
    Requires the following attributes: No attribute is required.
    Allows the following attributes: booleanvalue, contentvalidationname,
    currency, datevalue, formula, numbercolumnsrepeated, protect,
    stringvalue, stylename, timevalue, value, valuetype.
    These elements contain table.CoveredTableCell: table.TableRow.
    The following elements occur in table.CoveredTableCell: dr3d.Scene,
    draw.A, draw.Caption, ...
    So merged cells are refered to as covered cells is it?
    so odfpy, at least, can create such elements.
    Do you have any code sample done in odfpy which I can browse throu and
    run it to see the results.
    Here's an example of 2 merged ranges: A1:C2 contains the text "foo"
    and D1:D2 contains "bar"

    <table:table-row table:style-name="ro1">
    - <table:table-cell table:style-name="ce1" office:value-type="string"
    table:number-columns-spanned="3" table:number-rows-spanned="2">
    <text:p>foo</text:p>
    </table:table-cell>
    <table:covered-table-cell table:number-columns-repeated="2" />
    - <table:table-cell table:style-name="ce1" office:value-type="string"
    table:number-columns-spanned="1" table:number-rows-spanned="2">
    <text:p>bar</text:p>
    </table:table-cell>
    </table:table-row>
    - <table:table-row table:style-name="ro1">
    <table:covered-table-cell table:number-columns-repeated="4" />
    </table:table-row>

    Aside: If you are wondering where the cell addresses (D1 etc) are,
    they're in the reader's current_row and current_col variables :-)
    Perhaps this was intended to save space, but what of table:number-
    columns-repeated="4" ??
    I guess I got the point, but still can't figure out how I could actually
    implement this because I find the documentation of odfpy pritty complex
    and does not have the kind of example which shows what you explained in
    the above code.

    And the problem is that I got a bit confused in the above code because
    my merging happens only in the top row and spanns columns not rows.

    I would be very happy if I could get the code wich creates a set of
    merged cells in a single row with some data in it.

    I managed to do the odt part in the odfpy because the examples were
    there and well documented.

    happy hacking.
    Krishnakant.
  • John Machin at Mar 9, 2009 at 2:00 pm

    On Mar 9, 6:40?pm, Krishnakant wrote:
    Hi Terry,

    Well, You did reply i know, but seems i lost that mail some where,
    My mail client must have messed up the mail.
    It sure messed up when it hijacked two existing threads when sending
    messages, so I'm not surprised if it's filing incoming mail in the
    wrong place :-)
    any ways thanks for your reply,
    Right now I am stuck very badly.

    The problem is that I am trying python-ooolib and did find the library
    pritty good.
    There's another one called ooolib-python; have you had a look at that?
    But the problem is that library is missing a major feature from my
    requirement context.
    I need to merge cells in a spreadsheet and this library won't do that.

    Do you know how I can work around this?
    Here's a radical suggestion: Ask the author directly, or pop a note in
    the suggestion box on the sourceforge tracker [hint: don't use your
    mail client for this].
    I tryed searching for py2odf but did ont find any results.

    Do you want me to continue on the previous thread (I will try and dig
    that out ).
    Nah, just hijack a third thread :-)

    Cheers,
    John
  • Krishnakant at Mar 10, 2009 at 11:35 am

    any ways thanks for your reply,
    Right now I am stuck very badly.

    The problem is that I am trying python-ooolib and did find the library
    pritty good.
    There's another one called ooolib-python; have you had a look at that?
    Can you provide the url? Actually I think I saw this library but it
    seems it is not well maintained and the author is no more active.

    I think it is supporting old formats if I am talking about the same
    library. So please send me the link so that I confirm my doubts.
    But the problem is that library is missing a major feature from my
    requirement context.
    I need to merge cells in a spreadsheet and this library won't do that.

    Do you know how I can work around this?
    Here's a radical suggestion: Ask the author directly, or pop a note in
    the suggestion box on the sourceforge tracker [hint: don't use your
    mail client for this].
    I did send him a message but did not get any reply for the email.

    I will put this request on sourceforge.net as per your suggestion any
    how.
    I tryed searching for py2odf but did ont find any results.

    Do you want me to continue on the previous thread (I will try and dig
    that out ).
    Nah, just hijack a third thread :-)
    Thanks for that suggestion, I am not that multi threaded *smile*.
    I have fixt my mail problem now so every things seems to be fine (untill
    i hyjak another thread by accident LOL!).

    happy hacking.
    Krishnakant.
  • John Machin at Mar 10, 2009 at 12:44 pm

    On 10/03/2009 10:35 PM, Krishnakant wrote:
    any ways thanks for your reply,
    Right now I am stuck very badly.

    The problem is that I am trying python-ooolib and did find the library
    pritty good.
    There's another one called ooolib-python; have you had a look at that?
    Can you provide the url? Actually I think I saw this library but it
    seems it is not well maintained and the author is no more active.

    I think it is supporting old formats if I am talking about the same
    library. So please send me the link so that I confirm my doubts.
    http://ooolib.sourceforge.net/ calls it ooolib-python, but in
    topsy-turvy land
    (http://packages.debian.org/unstable/python/python-ooolib) it's called
    python-ooolib but all you need in the end is import ooolib.

    Three are one and one is three :-)
  • Krishnakant at Mar 10, 2009 at 6:16 pm
    Hi John,

    I tryed this same library to begin with.

    python-ooolib is very good except that it misses a major feature of cell
    merging (spanning ).

    That is the point from which I started the thread.
    I even thought the author of that library will respond back but did not
    happen.

    Seams it is a very old library and no development happens on it.

    happy hacking.
    Krishnakant.

    On Tue, 2009-03-10 at 23:44 +1100, John Machin wrote:
    On 10/03/2009 10:35 PM, Krishnakant wrote:
    any ways thanks for your reply,
    Right now I am stuck very badly.

    The problem is that I am trying python-ooolib and did find the library
    pritty good.
    There's another one called ooolib-python; have you had a look at that?
    Can you provide the url? Actually I think I saw this library but it
    seems it is not well maintained and the author is no more active.

    I think it is supporting old formats if I am talking about the same
    library. So please send me the link so that I confirm my doubts.
    http://ooolib.sourceforge.net/ calls it ooolib-python, but in
    topsy-turvy land
    (http://packages.debian.org/unstable/python/python-ooolib) it's called
    python-ooolib but all you need in the end is import ooolib.

    Three are one and one is three :-)
  • Gabriel Genellina at Mar 8, 2009 at 8:50 pm
    En Sun, 08 Mar 2009 18:08:50 -0200, Martin v. L?wis <martin at v.loewis.de>
    escribi?:
    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
    merge.py attempts to import config.py but I can't find it...

    --
    Gabriel Genellina
  • Martin v. Löwis at Mar 8, 2009 at 9:03 pm

    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
  • Tim Golden at Mar 10, 2009 at 2:13 pm

    Martin v. L?wis wrote:
    First, it relies on config.py whose existence msi.py
    optionally ignores.
    Feel free to create a patch for that.
    http://bugs.python.org/issue5467

    TJG
  • Martin v. Löwis at Mar 8, 2009 at 9:03 pm
    merge.py attempts to import config.py but I can't find it...
    Just create an empty one.

    Martin
  • Tim Golden at Mar 8, 2009 at 10:19 pm

    Martin v. L?wis wrote:
    merge.py attempts to import config.py but I can't find it...
    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 at Mar 8, 2009 at 10:39 pm

    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
  • Tim Golden at Mar 9, 2009 at 5:51 am

    Martin v. L?wis wrote:
    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.
    OK.
    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).
    Understood.

    TJG
  • Tim Golden at Mar 9, 2009 at 10:24 pm

    Tim Golden wrote:
    Martin v. L?wis wrote:
    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.

    Latest attempt: merge.py runs but produces errors. Unfortunately
    I know next to nothing about what MSI's trying to do here, except
    in the most general sense that it's bringing auxiliary files into
    the main MSI database.

    I attach the merge.log output but I'll try to do some
    research to understand what's going on here in any case.
    In particular it's not clear to me whether the thing
    has worked but has just tripped up over some non-essential
    part, or whether these are real errors. (I really need
    to set up a virtual machine which doesn't have VS2008).

    For the record, running it by sticking execfile (merge) at
    the end of msi.py has the same effect.

    TJG
    -------------- next part --------------
    An embedded and charset-unspecified text was scrubbed...
    Name: merge.log
    URL: <http://mail.python.org/pipermail/python-list/attachments/20090309/afd4691d/attachment-0001.txt>
  • Martin v. Löwis at Mar 10, 2009 at 1:02 am

    I attach the merge.log output but I'll try to do some
    research to understand what's going on here in any case.
    In particular it's not clear to me whether the thing
    has worked but has just tripped up over some non-essential
    part, or whether these are real errors. (I really need
    to set up a virtual machine which doesn't have VS2008).
    AFAICT, it only complained about errors in merging _Validation.
    I'm not sure whether I get the same errors (I would have to
    check); those errors can safely be ignored. _Validation is
    only used if you want to validate the MSI file, and I think it
    complained because the data being merged are different than
    the data that were already there. This, in turn, is because
    the data already there are (or should be) the recommended values,
    whereas the CRT msm deviates from Microsoft's recommended values
    (IIRC).

    I also see that it fails to add custom actions into
    InstallExecuteSequence. I find that puzzling - apparently,
    it tries to merge the twice. Are you sure you didn't run it
    twice? It will certainly fail the second time.

    Regards,
    Martin
  • Tim Golden at Mar 10, 2009 at 5:55 am

    Martin v. L?wis wrote:
    AFAICT, it only complained about errors in merging _Validation.
    I'm not sure whether I get the same errors (I would have to
    check); those errors can safely be ignored. Good.
    I also see that it fails to add custom actions into
    InstallExecuteSequence. I find that puzzling - apparently,
    it tries to merge the twice. Are you sure you didn't run it
    twice? It will certainly fail the second time.

    I'll double check. There was a point at which I was execfile-ing
    it from within msi.py *and* running it separately, but I thought
    I'd fixed that.

    BTW what are your feelings on a patch to msi.py to change the
    names of the directories it's looking for to pick up the Tk
    licenses? It's a bit of a grey area since the only "canonical"
    reference I can find is the externals checkout from within
    tools\buildbot: you might as well argue that it's *that*
    which should be changed.

    For my own part, I can run on a patched version quite easily
    so there's no real urgency for me. I'm just about at the point
    when I can put together a from-scratch instruction sheet for
    erstwhile Python-Windows developers to build Python & pywin32
    including installers from checkouts.

    TJG
  • Martin v. Löwis at Mar 10, 2009 at 9:00 am

    BTW what are your feelings on a patch to msi.py to change the
    names of the directories it's looking for to pick up the Tk
    licenses? It's a bit of a grey area since the only "canonical"
    reference I can find is the externals checkout from within
    tools\buildbot: you might as well argue that it's *that*
    which should be changed.
    Never touch a running system :-) If I can leave the tcl directories
    where I have them, and just check them out a second time (or
    perhaps just the license), that would be fine with me.

    Regards,
    Martin
  • Tim Golden at Mar 10, 2009 at 9:12 am

    Martin v. L?wis wrote:
    BTW what are your feelings on a patch to msi.py to change the
    names of the directories it's looking for to pick up the Tk
    licenses? It's a bit of a grey area since the only "canonical"
    reference I can find is the externals checkout from within
    tools\buildbot: you might as well argue that it's *that*
    which should be changed.
    Never touch a running system :-) If I can leave the tcl directories
    where I have them, and just check them out a second time (or
    perhaps just the license), that would be fine with me.
    OK; I've added a step to my process which does a svn export
    with the other name, specifying a depth of files-only.

    TJG
  • Tim Golden at Mar 10, 2009 at 2:44 pm

    Martin v. L?wis wrote:
    I also see that it fails to add custom actions into
    InstallExecuteSequence. I find that puzzling - apparently,
    it tries to merge the twice. Are you sure you didn't run it
    twice? It will certainly fail the second time.

    Just to confirm: I'm certainly only running this once.
    Still getting the same errors. Log attached for
    completeness. However, the .msi installs (and Python
    runs) without issue on a virgin VirtualXP.
    And it passes the basic test suite ok.

    This isn't surprising if it's just a case of "I've already
    done that; I'm not doing it again" as you suggest. But
    I'm not sure what's causing it. Not worth worrying about
    too much, I expect.

    TJG
  • Tim Golden at Mar 10, 2009 at 5:07 pm

    Tim Golden wrote:
    However, the .msi installs (and Python
    runs) without issue on a virgin VirtualXP. And it passes the basic test
    suite ok.
    I lied. test_zipfile fails because the new(ish) zipdir.zip doesn't
    get carried across to the install. Patched in:

    http://bugs.python.org/issue5470


    A couple of other tests fail (test_platform & test_pep352) when
    running regrest, but I can't get them to fail otherwise.


    TJG

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedMar 6, '09 at 8:52a
activeMar 12, '09 at 10:21p
posts43
users10
websitepython.org

People

Translate

site design / logo © 2022 Grokbase