TST/DOC: Test for and document incompatibility with openpyxl 2.0.0 and later

[neirbowj]

Let users down easy if v0.14.0 remains incompatible with openpyxl 2.0.0 and later

closes #7169 .

[jreback]

you can use LooseVersion for this much easier

look in pandas/init for how to use it

[neirbowj]

I read that LooseVersion was to be deprecated by PEP-386, but I guess that hasn't happened yet.

[jreback]

@jorisvandenbossche @cpcloud ?

[jreback]

@neirbowj pls squash down to 1 commit

[jreback]

@neirbowj

this is failing the 3.4 build (which has 2.03 of openpyxl).

https://travis-ci.org/pydata/pandas/jobs/25839724

I think you might need to leave openpyxl in the engine map by just have its value of None

then you can skip tests when the writer is None

something like that

[neirbowj]

@jreback So "Allowed Failures" aren't really? ;-)

The problem is not the writer registration, it looks like it's the version detection. I suspect that the too-old lxml is interfering. For some reason, pandas.compat.openpyxl_compat.is_compat() thinks that '2.0.3' is an incompatible version. I'll investigate.

[jreback]

they are just so the testing doesn't take too long

they r testing 3.4 and numpy 1.9

the 3.4 tests current versions of a lot of the deps (all the other deps are fixed)

so shouldn't fail

[neirbowj]

So... lxml has nothing to do with it. I proposed I would write a test that fails when an incompatible version of openpyxl is installed and I succeeded in doing so. If the tests as configured need to pass under 3.4, then that was the wrong spec. I should back out that test, and update pandas.io.tests.test_excel._skip_if_no_openpyxl to treat an incompatible version as "no openpyxl."

[jreback]

ok this all looks fine

should the warning be a UserWaarning?

pls squash to a single commit and can merge this

also pls open an issue for the actual modifications needed to support > 2.0
which can be worked on for 0.14.1

[jreback]

maybe an ImportWarning ?

[neirbowj]

openpyxl.xml itself uses the default (UserWarning) when it encounters the too-old lxml. I'm thinking we should follow that example.

def lxml_available():
    try:
        from lxml.etree import LXML_VERSION
        LXML = LXML_VERSION >= (3, 3, 1, 0)
        if not LXML:
            import warnings
            warnings.warn("The installed version of lxml is too old to be used with openpyxl")
            return False  # we have it, but too old
        else:
            return True  # we have it, and recent enough
    except ImportError:
        return False  # we don't even have it

[jreback]

ahh ok that's fine then

[jorisvandenbossche]

looking good

[jreback]

@neirbowj thanks!

[jreback]

@neirbowj

This just failed, seems odd, right? https://travis-ci.org/jreback/pandas/jobs/25910838

[neirbowj]

Yes, that does seem odd. I'm looking into it now.

[jreback]

I restarted the test and it DID recur

though it is NOT present in master atm; maybe had trouble installing the library....weird

[neirbowj]

The commit in this PR is not an ancestor of your categorical branch. Those two branches diverged just before I committed the workaround. Rebase and you'll be in good shape.