issue_comments

and in formatting_html.py

pkg_resources.resource_string("xarray", fname).decode("utf8")

This is used for pulling out static files (CSS/HTML) for xarray's HTML repr.

We could inline these resources as Python strings, but I think using separate files is cleaner and to my knowledge there is no better alternative than pkg_resources prior to Python 3.7.

On Python 3.7 we could use importlib.resources: https://docs.python.org/3/library/importlib.html#module-importlib.resources

I'm not here to argue, but pyproject.toml was introduced in PEP-518, which was accepted over 4 years ago. I know packaging moves slowly but I'm curious how long something has to be around before becoming "established" and ceases to be "novel". 😉

It looks like pip has supported pyproject.toml since version 10.0.0, on 2018-04-14. That's more recent than Python 3.6 (which, to be fair, we are about to drop support for).

Consistent with my earlier suggestion about setuptools, I think we should support the oldest packaging tools that were released at the time of our earliest supported Python release. So if we switch to requiring Python 3.7 in our next major release, we could switch to using pyproject.toml, too.

My preference would be to say that we support setuptools 30.3 and newer, even if we can't test it:

1. setuptools is extremely stable, compared to any of our other dependencies. I have a very hard time imagining any of the limited functionality we use breaking.
2. It is apparently tricky to upgrade, at least it can't be done automatically with pip install on some platforms.

I don't think it's worth the hassle of switching to importlib backports, at least for now. Likewise, I would lean against switching to pyproject.toml until it is well established. There's just not much to be gained by switching to novel packaging technology...

I'm preparing a PR...

Thanks! This is greatly appreciated :)

I think setuptools should be treated more like Python/NumPy because it's hard installation requirement (and can be challenging to install).

The requirement is explicitly set in setup.cfg because don't ship what you don't test.

My sense is that setuptools is somewhat unique as a dependency because it's only used as part of installation

I am supportive of bumping minimum version requirements according to our policy when it serves a purpose, but I don't think we should do it "just because we can".

I see no problem in explicitly adding a special case to the policy for setuptools - I guess 24 months should be fine for all? I do not recommend just going back to "whatever the very first version that works" as we were doing before the introduction of the rolling policy.

24 months sounds about right to me. Or given that setuptools is typically bundled with Python, maybe "Whatever version of setuptools corresponds to our oldest supported Python release"?

(This is assuming that it's still possible to get that version of setuptools in CI environments. If not, we may need to reconsider...)

It looks like the actual hard requirement for setup.cfg may be setuptools 30.3.0 from 8 December 2016: https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files

This is shortly before the release date of Python 3.6.0, so I suspect this would be a fine requirement to impose for our users.