html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/4295#issuecomment-668793103,https://api.github.com/repos/pydata/xarray/issues/4295,668793103,MDEyOklzc3VlQ29tbWVudDY2ODc5MzEwMw==,1217238,2020-08-04T19:52:30Z,2020-08-04T19:52:30Z,MEMBER,"> 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","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,671019427
https://github.com/pydata/xarray/issues/4295#issuecomment-668401159,https://api.github.com/repos/pydata/xarray/issues/4295,668401159,MDEyOklzc3VlQ29tbWVudDY2ODQwMTE1OQ==,1217238,2020-08-04T06:13:36Z,2020-08-04T06:13:36Z,MEMBER,"> I'm not here to argue, but `pyproject.toml` was introduced in [PEP-518](https://www.python.org/dev/peps/pep-0518/), 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.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,671019427
https://github.com/pydata/xarray/issues/4295#issuecomment-668383854,https://api.github.com/repos/pydata/xarray/issues/4295,668383854,MDEyOklzc3VlQ29tbWVudDY2ODM4Mzg1NA==,1217238,2020-08-04T05:14:32Z,2020-08-04T05:14:32Z,MEMBER,"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...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,671019427
https://github.com/pydata/xarray/issues/4295#issuecomment-667571656,https://api.github.com/repos/pydata/xarray/issues/4295,667571656,MDEyOklzc3VlQ29tbWVudDY2NzU3MTY1Ng==,1217238,2020-08-01T18:40:35Z,2020-08-01T18:40:35Z,MEMBER,"> I'm preparing a PR...

Thanks! This is greatly appreciated :)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,671019427
https://github.com/pydata/xarray/issues/4295#issuecomment-667571613,https://api.github.com/repos/pydata/xarray/issues/4295,667571613,MDEyOklzc3VlQ29tbWVudDY2NzU3MTYxMw==,1217238,2020-08-01T18:40:16Z,2020-08-01T18:40:16Z,MEMBER,"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...)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,671019427
https://github.com/pydata/xarray/issues/4295#issuecomment-667559947,https://api.github.com/repos/pydata/xarray/issues/4295,667559947,MDEyOklzc3VlQ29tbWVudDY2NzU1OTk0Nw==,1217238,2020-08-01T17:01:48Z,2020-08-01T17:01:48Z,MEMBER,"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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,671019427