With tests and examples being in the package, it's possible to run some useful tests of installed packages. This is what pyctdev does by default before uploading packages.
We could specify extra stages on our own CI that use different sets of channels (one defaults, the other conda-forge). The only problem there is the extra builds that would generate.
An alternative would be to add test commands to the c-f conda recipes:
[...]
test:
[...]
commands:
- datashader install-examples --path=.
- datashader download-data --datasets=small # or whatever we do in the end to achieve this
- pytest --nbsmoke-run # unit tests and run examples
c-f's CI will then test our packages on top of the c-f stack before making the packages available. Meanwhile, if our own CI is testing on top of defaults (which it is, using those commands), this should cover both sets of users. (It wouldn't continuously cover c-f users, just at (dev) package release time, but that is not too bad.)
With tests and examples being in the package, it's possible to run some useful tests of installed packages. This is what pyctdev does by default before uploading packages.
We could specify extra stages on our own CI that use different sets of channels (one defaults, the other conda-forge). The only problem there is the extra builds that would generate.
An alternative would be to add test commands to the c-f conda recipes:
c-f's CI will then test our packages on top of the c-f stack before making the packages available. Meanwhile, if our own CI is testing on top of defaults (which it is, using those commands), this should cover both sets of users. (It wouldn't continuously cover c-f users, just at (dev) package release time, but that is not too bad.)