Windows install to custom location after building from source
dan.erik...@gmail.com
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...@gmail.com
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
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
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
--
Gabriel Genellina
dan.erik...@gmail.com
> dan.erik.peter...@gmail.com schrieb:
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
>> 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?
>
> 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
Scott David Daniels
> ... 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....@Acm.Org
"Martin v. Löwis"
> 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"
> 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
>> 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
Tim Golden
> 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
"Martin v. Löwis"
> 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
>> 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
Gabriel Genellina
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
Krishnakant
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"
> 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"
Just create an empty one.
Martin
"Martin v. Löwis"
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.)
--
JanC
Tim Golden
>> 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"
>
> 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
> 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.
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.
>
> 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
Krishnakant
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.
John Machin
> 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
Terry Reedy
> 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.
>
> Right now I am stuck very badly.
>
> The problem is that I am trying python-ooolib and did find the library
> pritty good.
> 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
John Machin
> 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
Tim Golden
> 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
"Martin v. Löwis"
> 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
Terry Reedy
> On Mar 10, 6:55 am, Terry Reedy <tjre...@udel.edu> 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
Tim Golden
> 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
Krishnakant
> 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.
>
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.
Krishnakant
> 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.
"Martin v. Löwis"
> 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
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
Krishnakant
> > 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?
>
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
>>> 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?
>>
> 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 :-)
Tim Golden
>> 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
Tim Golden
> 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
> 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
Krishnakant
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?
> >>
Tim Golden
> 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
> 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....@Acm.Org
Tim Golden
Thanks for the feedback. I'm close to building the 3.1 release, too.
Just a few teething troubles.
TJG