Separate the dependencies into several extras

[fzhu2e]

To keep the core package more lightweight, it might be a good idea to separate the dependencies into several extras (see https://stackoverflow.com/questions/52474931/what-is-extra-in-pypi-dependency for the details).

This will allow other packages use some of the Pyleoclim classes without depending on too many dependencies that might not be really leveraged.

[CommonClimate]

I highly support that, and it makes sense when there are large packages that are seldom used within our codebase. The only one I can think of fitting both categories is sklearn, and of course the LiPD package, which is soon to be deprecated. Any other candidates on the "extra" chopping block?

[fzhu2e]

I see the current dependency list is not too long. Rethinking of this, I think the point is to improve compatibility and stability, i.e., dependencies that weaken compatibility and stability should be in the "extra" block. With this in mind, it would be nice if the following can be done:

1. Removing the constraints on version numbers for certain dependencies. ">=" maybe fine, but "<=" weakens compatibility.
2. Unstable dependencies should be in the "extra" block. I don't have a specific list in my mind, but I think our own packages are kinda unstable, so should be cautious on cross referencing at this stage.

[CommonClimate]

Well, this exemplifies the problem: our stack depends both on well-maintained, frequently updated packages like SciPy and less well maintained packages like Cartopy that break fairly often. We're not immune to that either. So I'm not sure what the solution is, because for practical purposes, if we don't pin certain packages, we find bugs every time. How do you handle that for cfr, @fzhu2e ? You have similar dependencies.

[fzhu2e]

In general, the strategy is to list only the minimum but highest level of dependencies. For example, in cfr, I don't specify scipy as a dependency because it's a dependency for other higher-level packages like seaborn. If there exists a conflict between seaborn and the latest scipy, seaborn will eventually fix it or at least provide version constraints when we install seaborn (we install seaborn explicitly but never do scipy explicitly, which will likely avoid the latest scipy being installed). Via this way, we leave the issue to the upstream instead of trying to fix everything by ourselves. Of course, this won't avoid every conflict, but at least will make things easier to handle.

[CommonClimate]

That sounds like a sensible path. I suggest creating a new branch in which you trim down setup.py and environment.yml until the CI tests pass (they are executed automatically when you generate a Pull Request). If we can get that to work with the current Cartopy/Scipy conflict, I'll be impressed...

[CommonClimate]

with the docs building and CI tests passing, I'm going to close this issue. However, we'll have to revisit this as time goes on, perhaps as early as the resolution of the Cartopy/SciPy conflict