Define intake.drivers entrypoints.

[danielballan]

This PR adds support for the new driver discovery mechanism added in intake/intake#236. It does not change the behavior of intake-xarray with older versions of intake.

[martindurant]

Is there any way to test this? Perhaps that the initial Intake import does not issue the FutureWarning.

[danielballan]

That's a good idea. We would need a version of intake that issues that FutureWarning in order to test for it though.

[martindurant]

I see this now:

In [1]: import intake
/Users/mdurant/code/intake/intake/source/discovery.py:133: FutureWarning: The drivers {'parquet': <class 'intake_parquet.source.ParquetSource'>, 'xarray_image': <class 'intake_xarray.image.ImageSource'>, 'netcdf': <class 'intake_xarray.netcdf.NetCDFSource'>, 'opendap': <class 'intake_xarray.opendap.OpenDapSource'>, 'rasterio': <class 'intake_xarray.raster.RasterIOSource'>, 'remote-xarray': <class 'intake_xarray.xarray_container.RemoteXarray'>, 'zarr': <class 'intake_xarray.xzarr.ZarrSource'>, 'fits_array': <class 'intake_astro.array.FITSArraySource'>, 'fits_table': <class 'intake_astro.table.FITSTableSource'>, 'athena': <class 'intake_sroka.sources.AthenaSource'>, 'google_analytics': <class 'intake_sroka.sources.GASource'>, 'google_sheet': <class 'intake_sroka.sources.GSheetSource'>} do not specify entry_points and were only discovered via a package scan. This may break in a future release of intake. The packages should be updated.
  FutureWarning)

[danielballan]

I see that on intake master, but it looks like this CI runs against the latest intake conda package, not intake master.

[martindurant]

That is probably intentional :)

We should probably have nightly builds on intake/intake which tests master against the most important driver packages...

[danielballan]

Right, agree. We have a bit of a chicken-and-egg problem here: it would be nice to update the most important driver packages before pushing the next intake release out to spare users that FutureWarning. But we can't test for the FutureWarning in CI until the next intake release is out....

How about I add a test that maybe skipped conditional on a version check with intake, confirm it passes locally against master, and go from there?

[martindurant]

Perfect

[danielballan]

We should probably have nightly builds on intake/intake which tests master against the most important driver packages...

Another way to do this is to set up nightly builds on each important downstream project that tests against intake master, as we did here.

[martindurant]

Hm, it depends on whether we expect the maintainers of the individual packages to notice (in possibly a number of places), or if only Intake maintainers get notified, and then need to inform others about possible upcoming issues. So long as it's only me, I'd prefer to keep things in one place, but I hope not to be main/only maintainer for long!

[danielballan]

That's a reasonable position. And there's no reason we can't take both approaches.

[danielballan]

Back to the topic of this PR: I pushed a commit adding a test. I wasn't thinking clearly earlier when I suggested a version check / skip-test approach. It's sufficient to assert that no FutureWarning is issued and then verify locally that the test still passes against intake master. I also verified that the test fails if run without the entry_points added in f63499c.

[martindurant]

OK, fair enough. Thanks for doing this.