Hi,
On 2015-12-15 23:54, Nathan Scott wrote:
> ----- Original Message -----
>
>> I checked the available Python XLSX modules at
>>
>> http://www.python-excel.org/
>>
>> and decided to use
>>
>> https://pypi.python.org/pypi/XlsxWriter
>
> This snippet also presents a problem from a packaging POV ...
>
>> +try:
>> + import xlsxwriter
>> +except:
>> + pass
>
> We need to capture this dependency in the rpm packaging, for example, to
> ensure that module is installed along with the script using it.
hmm, earlier I searched for xls / excel related packages and found
nothing, now that sheet2pcp was mentioned I searched also for sheet.
None of the related Python modules are available for RHEL/EPEL 6 but
(the barely maintained) xlwt is available for RHEL/EPEL 7 (xlwt has
received one commit during the past six months, the two most active
modules receive more commits during an average week). openpyxl would be
available for Fedora only (so not for RHEL/EPEL). It should be pretty
trivial to switch from xlsxwrite to openpyxl if wanted but that still
wouldn't help with RHEL/EPEL (pip would help with that, as it does with
xlsxwriter).
> This is part of the bigger high-level API problem I think i.e. that pmrep
> shouldn't become a monolith, importing a new module for every new feature
Yeah, at this point it's helpful to see what potential modules need from
pmrep "core" but as discussed earlier modularization would be
beneficial, both from development/maintenance and packaging point of view.
> Another alternative approach may be to
> use sheet2pcp(1) to verify the result?
Interesting, I hadn't heard about sheet2pcp(1) before. Seems that it's
not packaged for Fedora / RHEL. After installing few required RPMs and
Spreadsheet::Read from CPAN I was able to get it running and it looks
like it works (had to do tiny tweak to instance presentation in the xlsx
output to match PCP not sar2xls convention). A warning is printed but
the generated archive looks to be just fine:
Use of uninitialized value in subroutine entry at sheet2pcp line 571.
Since the actively developed Python XLSX modules might occasionally
change their output (e.g. a white-space or a bug fix change) then a
diff(1) based comparison might cause false alarms too often, this
sheet2pcp(1) test would actually sound like a good idea, we'd be testing
sheet2pcp(1) more as well in the process.
Thanks,
--
Marko Myllynen
|