CI: add `jinja2` as a hard dependency for `DataFrame.to_latex/to_html`
State: closed

As per https://github.com/pandas-dev/pandas/pull/43161#issuecomment-909765165

Goes towards #43161 and #41648

This is WIP since 41648 is not finished yet, but it is getting close.


Labels:
name: IO HTML
description: read_html, to_html, Styler.apply, Styler.applymap
name: Dependencies
description: Required and optional dependencies
name: Stale

Comments:
> You need to add this to the python-dev dependencies file, too. If we are going to go with this, our wheel building repos(Macpython, conda-forge) will also need updating too.

do you have any examples of PRs done this before - sorry never specifically built and released packages myself.
> > You need to add this to the python-dev dependencies file, too. If we are going to go with this, our wheel building repos(Macpython, conda-forge) will also need updating too.
> 
> do you have any examples of PRs done this before - sorry never specifically built and released packages myself.

That's fine, I can do it for you if you want. In case you want to take a look, https://github.com/MacPython/pandas-wheels is the repo for our pip wheels and https://github.com/conda-forge/pandas-feedstock is the repo for conda-forge package. 

I think the main thing left to do for this PR is adding jinja2 to the python-dev yml file. Right now, jinja2 is getting pulled at install time, but we should explicitly specify it here.
https://github.com/pandas-dev/pandas/blob/011c016f6106cf08df45cf069863fc0b1397b84e/.github/workflows/python-dev.yml#L44-L49.

We should probably discuss whether this is landing in 1.4 or 2.0 first in the other PR, though.

(P.S. It might be worth considering using the extra_requires section in setup.py instead of requiring this as a hard dependency. This would mean doing something like ``pip install pandas[html]`` for html support, where jinja2 would be an extra requirement. 
I'm not a huge fan of the jinja2 hard requirement since I'm pretty sure jinja2 comes with jupyter notebook AFAICT https://github.com/jupyter/notebook/blob/41f148395c2b056998768423257d9c8edb4244ec/setup.py#L111-L128 and since the other I/O methods all use optional dependencies. I don't have a strong opinion on this though.)
> We should probably discuss whether this is landing in 1.4 or 2.0 first in the other PR, though.

My plan was to try and use the jinja2 template scheme for `to_html` `to_latex` and `to_string`. Since this is such a large change (and difficult to get community approval and do all the work in time) I'm coming round to the idea that 2.0 is the best option. It also gives me a good cover to have more freedom with arg changes, especially if a warning has been issued in 1.4.0 without any implementation actually changing. (https://github.com/pandas-dev/pandas/pull/41648#issuecomment-922261990)

@attack68 I edited my comment above. I think jinja2 is a required dependency of jupyter so we should be able to close this PR(IIUC, the main concern was lack of support for jupyter notebooks when the non-jinja implementation was deprecated) and proceed directly with the deprecations.
> @attack68 I edited my comment above. I think jinja2 is a required dependency of jupyter so we should be able to close this PR(IIUC, the main concern was lack of support for jupyter notebooks when the non-jinja implementation was deprecated) and proceed directly with the deprecations.

Agreed, if we implement `to_html` and `to_latex` in terms of Styler then either:

a) Users of Jupyter already have jinja2 and can render it.
b) Web developers *likely* have jinja2, although not guaranteed, so they will have to add it as a web app dependency.
c) LaTeX users are probably rarer and will just need to install it if they are rendering to a script or a console output. If using Jupyter then they are OK.
d) Console users don't need it for displaying DataFrames since this is some form of string parser
This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.
closing this temporarily pending implementation in pandas 2.0