Improve code-base and coverage

[gnikit]

An attempt to remove some of the more obvious clutter

• not using super constructors and super method calls
• Remove code duplication
• Obstruct away certain methods
• Use objects were possible
• Simplify REGEX expressions (more can be done on this, I simply choose not to since the REGEX would be harder for me to read)
• Disable the autoversioning commit
• Further removal of format strings in favour of f-strings

[codecov]

Codecov Report

Merging #31 (6a71bea) into dev (80fdaa5) will increase coverage by 2.55%.
The diff coverage is 80.80%.

@@            Coverage Diff             @@
##              dev      #31      +/-   ##
==========================================
+ Coverage   78.46%   81.01%   +2.55%     
==========================================
  Files          10       10              
  Lines        4453     4288     -165     
==========================================
- Hits         3494     3474      -20     
+ Misses        959      814     -145     

Impacted Files	Coverage Δ
fortls/jsonrpc.py	61.58% <71.42%> (-2.26%)	⬇️
fortls/objects.py	80.70% <77.02%> (+1.46%)	⬆️
fortls/langserver.py	71.80% <84.37%> (+2.06%)	⬆️
fortls/_version.py	100.00% <100.00%> (ø)
fortls/helper_functions.py	86.40% <100.00%> (ø)
fortls/intrinsics.py	91.85% <100.00%> (+0.18%)	⬆️
fortls/parse_fortran.py	86.31% <100.00%> (+5.50%)	⬆️
fortls/regex_patterns.py	100.00% <100.00%> (ø)
... and 3 more

---

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 80fdaa5...6a71bea. Read the comment docs.

[ZedThree]

Hi @gnikit, thanks for taking up the maintainership of fortls, it's a really important community tool!

I notice here you've removed some code for auto-incrementing the version. I've recently been using setuptools_scm in all my python projects, which automatically sets the version from the latest git tag, and found it very useful.

If you're interested, I can open a PR implementing it.

[gnikit]

Hi @ZedThree, I will have a look at setuptools_scm. The code I commented out does not affect the releases of fortls just what is committed to the repo. I had to do it primarily for two reasons.

1. Currently we release on PyPi (and any other channel if we so choose to) through GitHub Releases. A Release creates the tag, and then proceeds to to build and upload the package. Updating that tag (via force push), predictably changes the status of the Release to a pre-release since its "state" has been altered. That is pretty annoying and somewhat defeats the point of having this automated since I then have to go manually and set the Release as not a pre-release.
2. Strictly speaking, signing the commit is actually a security vulnerability since any individual that can author a release would sign it with the key I uploaded, which really defeats the purpose of signing commits to improve security.

I suspect that setuptools_scm will run into issue 1), since GitHub will have already created the tag. I will definitely have a look though, feel free to open a PR, you can also locally test how github actions will perform by using https://github.com/nektos/act., e.g. act release.
I would suggest deleting all other yml files if you are to do this and also deleting the end part of python-publish all the PyPi release stuff.

[ZedThree]

Yep, that is how I automate releases too. setuptools_scm writes to a file that you add to .gitignore so it doesn't affect the state of the repo, and does this when you build the package, so there's no need to force push anything. It also has the added bonus that it can automatically create dev version numbers for non-tagged commits.

The downside is that using an editable install locally might not pick up changes to the version number without running setup.py or pip install -e . again. This isn't an issue if you always use the version from pypi though.

I didn't know about nektos/act, thanks!