Clean up the build process

[gselzer]

This PR is designed to incorporate the lessons learned from improving the build process of pyimagej and imglyb.

[codecov-commenter]

Codecov Report

Merging #38 (3dbb6a4) into master (b63a664) will increase coverage by 1.44%.
The diff coverage is 93.19%.

@@            Coverage Diff             @@
##           master      #38      +/-   ##
==========================================
+ Coverage   77.76%   79.20%   +1.44%     
==========================================
  Files           5        6       +1     
  Lines         697      755      +58     
==========================================
+ Hits          542      598      +56     
- Misses        155      157       +2     

Impacted Files	Coverage Δ
src/scyjava/config/__init__.py	57.33% <0.00%> (ø)
src/scyjava/__init__.py	70.84% <84.90%> (+1.42%)	⬆️
tests/test_version.py	87.09% <87.09%> (ø)
tests/test_convert.py	100.00% <100.00%> (+3.24%)	⬆️
tests/test_jvm.py	100.00% <100.00%> (+5.88%)	⬆️
tests/test_pandas.py	100.00% <100.00%> (+2.27%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b63a664...3dbb6a4. Read the comment docs.

[gselzer]

Major changes:

• Bumped minimum Python version to 3.7
• Rename environment-test.yml to dev-environment.yml and python-test-conda.yml to build.yml.
• Track version using setuptools_scm
• Added scyjava.__version__, and scyjava.version.version. The latter is generated during the build process, and the former will differ based on the repo status 😦
• Added the @module_property decorator; these are lru_caches by default.
• Added a flaking action using flake8, aligning our project with PEP 8

Open questions:

• The return of scijava.__version__ differs based on the state of your code. scijava.version.version only exists if you have a distribution, in which case scijava.__version__ will delegate to that. If you do not have a distribution, then scijava.__version__ uses another method (either importlib.metadata.version, if your Python is >=3.8, or pkg_resources if that is installed), but these returns differ from the return of scijava.version.version; they are less specific. If somehow none of those ways exist in the environment to get the version, then scijava.__version__ whines about not being able to determine the version. Can we do better? Do we need to do better?
• Can we write a test to test the version?

[gselzer]

TODO: clean up @module_property - @ctrueden suggested it should be renamed @constant, which I like.

We also have to make sure that these things cannot be mutated.

[gselzer]

I think this is ready for review @ctrueden.

I added a flaking job to Github Actions; this enforces code style. You can check the code style locally using flake8, which was added to the development environments. If you have flaking errors, they'll likely be fixed using autopep8, also added to the development environments. All of the flaking infrastructure is added in the last commit, so if you have a good reason against this addition we can easily remove it.

[ctrueden]

Yay! Thanks, @gselzer!