feat(generate_classes): create a command-line interface

[mwtoews]

This is a simple command-line interface for generate_classes() using the -m switch method with argparse, which is cleaner than using the -c command switch approach. E.g., compare:

- python -c 'import flopy; flopy.mf6.utils.generate_classes(ref="develop", backup=False)'
+ python -m flopy.mf6.utils.generate_classes --ref develop --no-backup

Built-in help is shown with python -m flopy.mf6.utils.generate_classes -h.

At this time, it is not added to [project.scripts] (like get-modflow) since this is generally a developer feature, not a user feature.

Also, not sure if this was overlooked from #1907, but the defaults to generate_classes() would always show:

DeprecationWarning: branch is deprecated, use ref instead

This is resolved by swapping these defaults to branch=None and ref="master".

Closes #1629

[codecov]

Codecov Report

Merging #1912 (2127262) into develop (7237026) will decrease coverage by 0.1%.
The diff coverage is 19.0%.

@@            Coverage Diff            @@
##           develop   #1912     +/-   ##
=========================================
- Coverage     72.5%   72.5%   -0.1%     
=========================================
  Files          257     257             
  Lines        56276   56294     +18     
=========================================
+ Hits         40849   40853      +4     
- Misses       15427   15441     +14     

Files Changed	Coverage Δ
flopy/mf6/utils/generate_classes.py	17.6% <19.0%> (+0.8%)	⬆️

[wpbonelli]

Thanks @mwtoews I did overlook the defaults in 1907.

I wonder if this could see use beyond developers e.g. modelers beta testing unreleased versions of modflow6. Are there downsides to adding a project.scripts command besides occupying the command name, e.g. gen-classes or create-packages?

[mwtoews]

There's no big downsides, it just creates several objects (e.g. an .exe wrapper for Windows). These do get cleaned-up with pip uninstall flopy too. My rationale on "why not" is that most users won't need it.

Calling modules in Python is pretty common (e.g. python -m numpy.f2py -h).

[mwtoews]

Another future consideration is to expose a top-level flopy command with sub-commands. E.g.

$ flopy generate_classes -h

and I say future consideration, since there could be other potential sub-commands. A few ideas:

• flopy info to get basic information on a model
• flopy plot to generate plots from a model and/or simulation resullt

And probably others. You can see example sub-commands with git -h to get an idea of what I'm thinking.

[jdhughes-usgs]

@w-bonelli not sure if your recent CI changes impact this PR.

[wpbonelli]

I think this should not present any CI issues.

The top-level flopy command with subcommands seems nice from a user perspective and it would also disambiguate any potential overlap with non-flopy commands. Maybe before the next minor release that could be implemented for this and get-modflow.