CI: Ignore this
just trying from a different branch.

try

`conda install libpng=1.5.13`

I think the latest `qt/pyqt` installs the latest `libpng` which seems broken
 just add `libpng=1.5.13` in `ci/requirements-2.7_SLOW.build`
 I'll try that next, that seems to be the version picked up though: https://travis-ci.org/pydata/pandas/jobs/90647120#L909. `libpng:         1.5.13-1`
 hmm when I did this on s vm it installed pyqt and not pyside that is very odd (same version of qt though)
 I don't even know anymore.... for whatever reason https://github.com/pydata/pandas/commit/428259aae91550af17ca06c4ec3fdab00e0b6945 kicked off two Travis runs, [1](https://travis-ci.org/pydata/pandas/builds/90647106) which failed on 2.7 so I killed it, and [2](https://travis-ci.org/pydata/pandas/builds/90647118) which is still running, but has gotten past the point of failure. (And now it's finished green).
 @TomAugspurger any luck on this?

did you specify using `pyqt` directly so it doesn't install `pyside`.
 let me try pyqt, any specific version?
 this worked for me on a local vm (after failing with the same errors as on travis) when I fixed
libpng, but also try fixing `qt=4.8.5` and `pyqt=4.10.4`
 note that these are slightly older versions
 side issue, we should prob just drop testing with mpl 1.2.1 (make an issue), as even mpl doesn't support older than 1.4
 Yeah, I went with the newest. I'll try those next.

If this doesn't work then I've got a new clean repo and I'll just copy over my changes a couple at a time to see when it breaks.
 https://travis-ci.org/pydata/pandas/builds/90940774 failed with unsatisfiable dependencies (most recent version of pyqt and the mpl 1.2.1).

Trying with the older pyqt and qt now in https://travis-ci.org/pydata/pandas/builds/90943124
 Same [libshiboken errors on 2.7](https://travis-ci.org/pydata/pandas/jobs/90943126) when setting pyqt and qt.
 is that the only build failing? just take jinja2 out then.. :<
 It fails with or without Jinja though, which makes no sense at all. There's semi-regularly segfaults on the 3.4 build.

I'm just stepping through all the possibilities from this fresh branch today. I'll keep updating the thread with the results for reference.

| change | result | run | commit |
| --- | --- | --- | --- |
| update all CI files to jinja2 | :white_check_mark: | https://travis-ci.org/pydata/pandas/builds/90948455 | https://github.com/pydata/pandas/commit/568b20b3f804f8d96033d6355a63348707b684c6 |
| update CI files excluding problematic 2.7 | :x: | https://travis-ci.org/pydata/pandas/builds/91062994 | https://github.com/pydata/pandas/commit/92e8eec4e4e85cfaf3f6d3b20214c9188cd2f3fe |
| update code only, not ci |  |  |  |
| update code and ci | :x: | https://travis-ci.org/pydata/pandas/builds/90972841 | 0800cb1 |
| rename to htmlstyle | :x: | https://travis-ci.org/pydata/pandas/builds/91105102 | https://github.com/pydata/pandas/commit/af442de44bc6e82a03ff8f86ca66cad3e666f6f7 |
| don't import jinja (no tests) | :white_check_mark:ish | https://travis-ci.org/pydata/pandas/builds/91112568 | https://github.com/pydata/pandas/commit/aab41f7ea1fd01cfdb743a1bb70df17dbf707a7c |
| import jinja, no tests | :white_check_mark: | https://travis-ci.org/pydata/pandas/builds/91114804 | https://github.com/pydata/pandas/commit/815a3420d4cb1374360ee883d3d90ee9044af5a0 |
| tests with module skip | :x: | https://travis-ci.org/pydata/pandas/builds/91128582 | https://github.com/pydata/pandas/commit/af6ba4849fad588ecc501104d93d593d4d19ad83 |
| skip if environ var |  | https://travis-ci.org/pydata/pandas/builds/91129650 | https://github.com/pydata/pandas/commit/fa3c3594fb631817266f0cfb9dcc980d1b7566f5 |
 @TomAugspurger side thing. update `utils/print_version.py` for `jinja2/markupsafe` as well
 This is strange right? The failing build is only build 2, `27_slow_nnet_LOCALE`. It [_doesn't_ fail](https://travis-ci.org/pydata/pandas/builds/90948455) if we install Jinja2. It only fails when my actual code is included, _[whether](https://travis-ci.org/pydata/pandas/builds/90972841) or [not](https://travis-ci.org/pydata/pandas/jobs/91062996) Jinja is installed_... So it's either
- _trying_ to import Jinja (successfully or not) triggers the fail
- My `core/style.py` or the  `tests/test_style.py` is doing something
 did u try renaming core/style.py ?
 Yeah, let me try it from this branch though.
 @jreback so I think [this](https://travis-ci.org/pydata/pandas/builds/91114804) succeeding narrowed it down to _trying to import Jinja_. Doesn't matter whether it's installed or not. Removing the tests means that it just isn't imported. I try to import it in the toplevel of `pandas.core.Style`, but I don't think that code was run at all in the last build. The only other option I see is something in my tests causing the failure, other than trying to import jinja.

EDIT: that said, I'm not sure how to avoid it while still having the tests. I guess mark all the tests in `test_style` with something and exclude it on that 2.7 build with some nose argument?
