HARMONY-388: Better consistency across Python repos

[vinnyinverso]

What follows are the acceptance criteria and what I found or did to address them. (I also spoke with Chris prior to submitting this PR.)

• Consistent python environment setup and use across the 3 repos
  • For all but the harmony-service example, the READMEs were suggesting to use some combination of pyenv, pyenv-virtualenv, or venv. I tried to update the READMEs so that it was clear to the reader that all of these were acceptable tools.
• Either build scripts or make across the 3 repos
  • All of the regular (non-Docker service) Python module/lib repos (harmony-service-lib, harmony-py) use make files. All of the Docker/service-oriented repos (harmony-netcdf-to-zarr, harmony-service-example) use build scripts because they seem more conducive to the scripting logic needed to satisfy some of the more complex build logic. This seemed like a reasonably consistent solution (makefiles for pure libraries and build scripts for docker services).
• Consistent way of installing deps across the 3 repos
  • All except one repo are using pip for installing dependencies in a fairly consistent manner, with one requirements file for dev, and one for core requirements. The only repo not following this pattern is the harmony-service-example, which uses conda. However, conda is a recommended way of installing one of the main dependencies of this repo (gdal) whereas pip is not (and is difficult to use in this instance from my experience). The use of conda, is also still compatible with the aforementioned recommended Python version manager and virtual env tools.
• Consistent linting across the 3 repos
  • All repos (except for harmony-service-example) use flake8. We could add flake8 to harmony-service-example if desirable. I'm guessing it wasn't added due to the simplicity of the example.
• Consistent unit testing framework and execution across the 3 repos
  • I believe Patrick said there was another ticket addressing this.
• Consistent CI/CD across the 3 repos
  • Much of this seems to be adequately addressed by the recent transition to GitHub and related work.
• Update READMEs across the 3 repos to document the consistent tools, packages, and configuration for setting up a dev environment; dev environment does not presume editor
  • I updated 3 READMEs to give more consistent suggestions on virtual environment setup. None of the dev environment setups assume the user has a specific editor.

[chris-durbin]

Just curious - what is this file?

[vinnyinverso]

The readme recommended creating a virtual environment called harmony-ntz with pyenv-virtualenv. If you use venv to do the same, it creates a directory with that name for the virtual environment.

[vinnyinverso]

I'm guessing people have not been using the virtual environment naming suggested in the readme in favor of something like "venv". (I used harmony-ntz when I created my virtual environment because that seemed to be what was being suggested.)

[bilts]

I've been using pyenv virtualenv, but for consistency with ourselves and other projects I've seen and easier setup of $PATH, it may be better to just have the environment called env (or venv or you pick one) in every project, so we can run the same source env/bin/activate everywhere and have the same gitignore everywhere.

[bilts]

Nice work. If you're editing the README again, you may want to mention up front that you can also just docker pull harmonyservices/netcdf-to-zarr

[bilts]

I've been using pyenv virtualenv, but for consistency with ourselves and other projects I've seen and easier setup of $PATH, it may be better to just have the environment called env (or venv or you pick one) in every project, so we can run the same source env/bin/activate everywhere and have the same gitignore everywhere.