We shouldn't require a recent version of setuptools to install xarray

[shoyer]

@canol reports on our mailing that our setuptools 41.2 (released 21 August 2019) install requirement is making it hard to install recent versions of xarray at his company:
https://groups.google.com/g/xarray/c/HS_xcZDEEtA/m/GGmW-3eMCAAJ

Hello, this is just a feedback about an issue we experienced which caused our internal tools stack to stay with xarray 0.15 version instead of a newer versions.

We are a company using xarray in our internal frameworks and at the beginning we didn't have any restrictions on xarray version in our requirements file, so that new installations of our framework were using the latest version of xarray. But a few months ago we started to hear complaints from users who were having problems with installing our framework and the installation was failing because of xarray's requirement to use at least setuptools 41.2 which is released on 21th of August last year. So it hasn't been a year since it got released which might be considered relatively new.

During the installation of our framework, pip was failing to update setuptools by saying that some other process is already using setuptools files so it cannot update setuptools. The people who are using our framework are not software developers so they didn't know how to solve this problem and it became so overwhelming for us maintainers that we set the xarray requirement to version >=0.15 <0.16. We also share our internal framework with customers of our company so we didn't want to bother the customers with any potential problems.

You can see some other people having having similar problem when trying to update setuptools here (although not related to xarray): https://stackoverflow.com/questions/49338652/pip-install-u-setuptools-fail-windows-10

It is not a big deal but I just wanted to give this as a feedback. I don't know how much xarray depends on setuptools' 41.2 version.

I was surprised to see this in our setup.cfg file, added by @crusaderky in #3628. The version requirement is not documented in our docs.

Given that setuptools may be challenging to upgrade, would it be possible to relax this version requirement?

[shoyer]

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.

[crusaderky]

I was surprised to see this in our setup.cfg file, added by @crusaderky in #3628. The version requirement is not documented in our docs.

It is documented:
https://xarray.pydata.org/en/stable/installing.html#minimum-dependency-versions

xarray adopts a rolling policy regarding the minimum supported version of its dependencies:
[...]
all other libraries: 6 months

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

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.

I'm preparing a PR...

[shoyer]

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...)

[shoyer]

I'm preparing a PR...

Thanks! This is greatly appreciated :)

[ChrisBarker-NOAA]

As I said in the mailing list thread, if setuptools is only required for installation, it's not really a requirement at all. In fact, I'm pretty sure pip requires it, so it will always be there if pip is there.

But I see:

install_requires =
    numpy >= 1.15
    pandas >= 0.25
    setuptools >= 41.2  # For pkg_resources

in setup.cfg -- so if you are using pkg_resources at run time, then you do need it here, in some version :-(

(the :-( is for pkg_resource being built in to setuptools -- it REALLY should be a separate package~!)

In regards to "don't ship what you don't test" -- if you take that philosophy, which is a good one, then you should be testing with-as-old-as-they-can-be versions of the dependencies anyway. which it looks like #4296 is doing :-)

[crusaderky]

then you should be testing with-as-old-as-they-can-be versions

We used to do that and we abandoned that policy in favour of the current rolling window, because it made developers (particularly the less experienced ones) waste a considerable amount of effort retaining backwards compatibility with obsolete versions of the dependencies that nobody cared about.

[crusaderky]

setuptools-scm doesn't work with setuptools < 36.7 (Nov 2017).
The conda metadata is malformed for setuptools < 38.4 (Jan 2018) - it's missing a timestamp which prevents the minimum versions tool from working.

Is everybody happy with >= 38.4?

[ChrisBarker-NOAA]

it made developers (particularly the less experienced ones) waste a considerable amount of effort retaining backwards compatibility with obsolete versions of the dependencies that nobody cared about.

that all depends on what you mean by "as-old-as-they-can-be" means -- to me, it means as old as they can be that have the features you need. IN this case, setuptools was being upgraded, even though xarray didn't need any of the new functionality.

What are you actually using for development? One option is to keep versions pinned to old versions until a developer wants a feature that requires a newer version -- then you update that one, if it's within your rolling window

But I can see that keeping track of what you need is tricky -- so the rolling window is a lot easier to manage

Honestly, the real problem here is that setuptools is both a build, install, and run-time dependency -- which is going to require special treatment.

[crusaderky]

The key problem in "as-old-as-they-can-be" is that you end up with dependencies that depend on each other and are 1 year apart in release date. Since very frequently other projects are a lot less rigorous with testing vs old dependencies (if they test at all!) that has caused an endless amount of breakages in the past. Testing with all packages as of 1 year ago is a lot less bug-prone and time-wasting.

[dopplershift]

Rolling window seems fine to me. I will say that I don't generally bother bumping that on other projects until we run into an issue/new feature that necessitates it, though.

[crusaderky]

PR ready for review

[keewis]

the reason we install-depend on setuptools is that we use pkg_resources for constructing the version with setuptools_scm and for getting the paths to images and css used for the HTML repr. Both of these can be replaced with modules in the standard library: importlib.resources (available since 3.7) and importlib.metadata (available since 3.8). Both also have backports (importlib-resources and importlib-metadata), so we should be able to get rid of the install-dependency on setuptools.

setup_requires has been deprecated in favor of specifying the build dependency in pyproject.toml. Maybe we should use that instead? That way we don't have to care about users failing to bootstrap setuptools because pip will create a isolated environment with just the build dependencies, build the source into a wheel and then install that without using setuptools. So I think that means you can have a old version of setuptools installed in your environment and still pip-install a package that requires a newer version.

An additional advantage is that our setup.py can become

from setuptools import setup

if __name__ == "__main__":
    setup()

(we can't remove setup.py entirely because it's required for editable installs)

[crusaderky]

importlib.resources (available since 3.7) and importlib.metadata (available since 3.8). Both also have backports (importlib-resources and importlib-metadata), so we should be able to get rid of the install-dependency on setuptools.

-1 from me, because dependencies that are only required on a specific Python version are incompatible with noarch conda recipes. This would force us to change conda to build one package for each OS x python version.

[keewis]

I was going to suggest using preprocessing selectors, but as you say these are incompatible with noarch because they're used at package build time, not when installing.

The pint recipe worked around that by unconditionally installing importlib_metadata, even on python 3.8. Not sure if that's the best option, though. Other than that, NEP29 states that we can drop python 3.6 since Jun 23 2020, so if we bump python we could use stdlib's importlib.resources.