issue_comments

Even if version information is (not yet) available, this would be very useful. Currently, when packaging xarray for downstream distributions, it is a very burdensome task to piece together which optional dependencies there are in the first place. I understand that dealing with the backlog makes this a rather tedious task, but making it a requirement going forward to add such dependency information whenever a dependency is changed or added would be required in any case.

Some of my workflows involve the manual creation and destruction of virtualenvs. On occasion, I've found myself wanting a pip install xarray[complete] much in the same way dask will do. The difference between dask and xarray, however, is that the "complete" submodules are part of dask and not optional external third party dependencies.

Alternatively, it might be nice to be able to query xarray for what its current serialization capabilities are.

WRT points: - right, it's not tracked and that's the motivation for this issue - just because it's not widely done is not a reason to ignore it and does not justify not doing it - IMO it is not widely done because many science projects are lapse in managing version dependencies using SEM-VER best practices, leaving it to the consumers, who are often clueless about these matters, to wonder why their project crashes with one or more dependencies that they don't understand nor care to dive into at any depth - many science projects avoid the whole problem by lagging with 0.x releases, failing to commit to stable, reliable APIs with at least 1.x releases - by adopting better SEM-VER practices, across the board, it should provide more confidence to arrive at 1.x releases. But this is not my battle to wage, I'm just the messenger for thousands of consumers who have no idea what versions are compatible or not.

Given that our optional dependencies can all be added individually, I'm a little skeptical that options like pip install xarray[netcdf4] provide much value over pip install xarray netcdf4. But I do appreciate the virtue of making this information programmatically accessible, and certainly would have no objection to contributors here.

But do note: - We currently do not keep track of version requirements for optional dependencies. It would take some investigation/testing to figure out what works. - This is not a widespread practice among Python data/numerical computing projects. For example, pandas does not do this.

Since xarray is operating as a meta-package with various wrappers, it is the only place that can apply version compatibility on it's dependencies. If there are optional dependencies, the python package extras are the process to manage them (not a README). The SEM-VER standards allow specification of more than one version for any dependency (so long as it complies with SEM-VER standards).

Essentially, this is a request for more sophistication in the setup.py file - https://github.com/pydata/xarray/blob/master/setup.py

Consider, for example, how Apache Airflow does it: - https://github.com/apache/airflow/blob/master/setup.py - https://github.com/apache/airflow/blob/master/setup.py#L353

We test xarray continuously against the latest released versions of all these dependencies (and older versions, too, in many cases). For xarray and netCDF4, for example, you could simply use pip install xarray netcdf4.

Are there particular subpackages you would suggest?