ci: install mf6 development build for CI tests

[wpbonelli]

• follow up to ci: install mf6 nightly build exes and update flopy pkgs #1824
• 1824 switched some CI testing to the mf6 development build, use it for all CI tests
• don't update flopy packages from DFNs before CI testing, test current repo state

The motivation here is that flopy's develop branch should test against the mf6 development build so the projects can be developed in sync. The move to update flopy packages in CI was misguided — we want to test the codebase as it exists in version control.

Master and release branches are still tested against the latest official mf6 release.

[codecov]

Codecov Report

Merging #1970 (f029c3d) into develop (4b105e8) will decrease coverage by 0.1%.
Report is 1 commits behind head on develop.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           develop   #1970     +/-   ##
=========================================
- Coverage     72.7%   72.7%   -0.1%     
=========================================
  Files          257     257             
  Lines        57810   57810             
=========================================
- Hits         42075   42057     -18     
- Misses       15735   15753     +18     

see 2 files with indirect coverage changes

[langevin-usgs]

This is good. I guess we will need to stay on top of any changes that we make on the MODFLOW 6 side. If we keep the definition files in flopy, we could compare flopy dfns with modflow6 dfns to help identify why there might be a failure? Or maybe there is a better way?

[wpbonelli]

After thinking on this more

The move to update flopy packages in CI was misguided — we want to test the codebase as it exists in version control.

the second part seems right in principle, but now I wonder if flopy needs to version package classes.

Flopy could cease versioning dfns and generated mf6 component classes, and instead package a copy of the latest dfns, and generate classes from it at install time. Flopy CI could fetch and test both the latest released dfns and the develop version. The flopy develop branch and releases could aim always to support (at minimum) the latest mf6 release and the develop version. Compatibility with older mf6 would need to be tested and if found lacking a recommendation to downgrade to a previous flopy seems appropriate?

This could help to make mf6 version support policy explicit and limit overhead to keep flopy and mf6 in sync. Autotests could test multiple mf6 versions with fairly little extra effort

It seems like this would not disturb the user experience — API reference would still be on ReadTheDocs, package classes would still be in the environment after installation, and it shouldn't add much time to the install process.

Some possible downsides:

• would intellisense still work?
• would this make debugging harder?

[wpbonelli]

I think MF6 class generation could be deferred to install time with a custom setuptools build command by extending setuptools.command.build.SubCommand. The second paragraph here makes it sound like this is not uncommon

A command that produces platform-independent files (e.g. compiling text templates into Python functions)