preserve leading zero's on xlsx output about tablib HOT 13 CLOSED

I am patching /tablib/formats/_xlsx.py on my local install to try to use Cell.set_value_explicit() when the value in the cell begins with a zero and its len() is greater than 1.

from tablib.

If it doesn't break anything, you should send a pull request :)

from tablib.

There is a little bit of refactoring I would like to do in dset_sheet()

from tablib.

Most of my assignments to ws.cell() are occurring in the TypeError except clause in _xlsx.py.

What I have is working, however, "if it doesnt break anything" has not been proven out.

I am under the gun with this report, so I am going to use this patch as-is. Can I send you a diff maybe to use against your unittests?

from tablib.

Is column ordering supported in various outputs? I am looking around,
but it appears that alphabetical by col_header is all that is
available.

from tablib.

It appears to export the columns in reverse order that they are imported. I am going to reverse that so the order of the columns is preserved.

from tablib.

This change keeps the order of columns in the xlsx output. Only the last line is changed. The others are there for context.

for i, row in enumerate(_package):
    row_number = i + 1
    for j, col in enumerate(row):
        col_idx = get_column_letter(len(row) - j)

from tablib.

That patch yesterday was naive. The order of columns does not appear to be controllable. It worked for one case, but stopped working when some new columns were added.

My reason for them falling into the TypeError probably stems from me running this on aix which is using a latin-1 encoding.

To preserve the leading zero's in openpyxl, it is just the difference between setting a cells value property and calling the method cell.set_value_explicit(value).

I attempted to detect when the cell contains a string with len gt 1 and position 0 is a zero. That never worked out (i think due to the latin-1 encoding.)

from tablib.

I have a fork that I am patching this and testing.

from tablib.

While working another project, I tried your xls output and it appears to "do the right thing" by default. So, it is only the openpyxl output I suspect.

from tablib.

This issue can be closed. It appears that Eric is patching openpyxl. I guess this issue can be used to patch your internal openpyxl.

References:
upstream issue 70
upstream issue 77

from tablib.

This commit specifically works a lot better than what you have currently.

https://bitbucket.org/ericgazoni/openpyxl/changeset/ea3779bcd3a5#chg-openpyxl/cell.py

from tablib.

This project is in a bit of a crisis state — it's really useful, and I use regularly. However, I wrote it several years ago and haven't touched it since. In order to get the project into a stable state I'm closing all issues and pull requests to get a "fresh slate"

Don't take this as aggressive — it's just necessary for the project to make any progress any time soon (it's pretty clear the project is effectively unmaintained at the moment). Great things to come! Please watch the GitHub logs and feel free to re-open this discussion soon. I just need to really it into a good state first.

✨ ❤️ ✨

from tablib.