Consider pinned versions in conda environments more carefully

[tsjackson-noaa]

@yihungkuo experienced numerous problems with his plotting scripts breaking under differing versions of matplotlib. In order for the framework-provided conda environments (for python, NCL and R) to be useful to POD developers, they need to provide a stable, reproducible set of dependencies.

We currently specify the major and minor version numbers in these environments, which were last changed in Jul 2020. In light of Yi-Hung's problems, though, we may need to get more specific that this. Unfortunately, if you ask conda to dump your environment, you get something that's not portable across platforms, since it includes the individual platform-specific builds of all packages.

For reference, the revision history for matplotlib indicates that changes in the third number are bugfix releases, while changes in the second number introduce new features. It may be that even the bugfix updates change so much that we want to stick with a fully specified version number, bugs and all.

[bitterbark]

I would like to see this along with named conda environments (ie. MDTF-base-v3.0beta3) so that users can switch back and forth between development versions.

[yihungkuo]

I agree with @bitterbark's suggestion.

Also, at some point, we should remind POD developers that while they can add new dependencies (with specific version numbers) to existing Conda environments, they should not change any existing dependencies.

[jkrasting]

I think having fixed package versions for the released versions of MDTF framework is a good idea. But we should also be on top of changes being made to the underlying packages to prevent things from going stale.

I would propose:

• A set of yml files with fixed versions that the setup script uses
• A second set of yml files without any version numbers (defaults to bleeding edge) to simultaneously test in CI

[tsjackson-noaa]

Converting this issue to a discussion topic because it doesn't have agreed-upon action items yet.