Use declarative setup.cfg; use setuptools_scm to set version

[ZedThree]

This does two related things:

1. switch to using the more modern declarative setup.cfg over setup.py
2. use setuptools_scm to set the version automatically

setup.py is slowly getting phased out in favour of setup.cfg. The main benefit is there's much less need for any kind of code, which means there's no chicken-and-egg problem with building the package -- this actually isn't a problem with fortls because it has no third-party dependencies.

setuptools_scm is really nice because it completely handles setting the version number. Running fortls --version on this commit now reports 2.0.2.dev7+g98adb50 -- this encodes how many commits since the previous release, along with the exact commit hash, while still being compatible with semver.

[ZedThree]

This partly replaces #31

[gnikit]

I will have a look but I would try and squeeze one thing per PR when it comes to the build system. Also, I am not so sure what happens to the documentation deployment with this, since it peaks up the version from _version.py which (from my understanding) will not have been generated unless we build the extension. The states between github actions do not persist

[gnikit]

Good job overall. I am slightly concerned about the documentation generation.
I will allow it to run on the CI and see how that goes.

[codecov]

Codecov Report

Merging #32 (1dc53de) into dev (0057f62) will decrease coverage by 0.08%.
The diff coverage is 54.54%.

@@            Coverage Diff             @@
##              dev      #32      +/-   ##
==========================================
- Coverage   81.02%   80.94%   -0.09%     
==========================================
  Files          10       10              
  Lines        4290     4298       +8     
==========================================
+ Hits         3476     3479       +3     
- Misses        814      819       +5     

Impacted Files	Coverage Δ
fortls/version.py	44.44% <44.44%> (ø)
fortls/interface.py	100.00% <100.00%> (ø)
fortls/langserver.py	71.85% <100.00%> (ø)

---

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 0057f62...1dc53de. Read the comment docs.

[ZedThree]

I've added .readthedocs.yaml in order to tell it to pip install the package and the extra requirements

[ZedThree]

I might suggest also replacing the docs Github Action with using readthedocs directly on PRs: https://docs.readthedocs.io/en/stable/pull-requests.html

[gnikit]

About the docs. I don't see a compelling reason to change/add to GitHub Pages readthedocs for this project. From my understanding readthedocs, as proposed here, would replace gh-pages. The existing Actions implementations work robustly with no maintenance required, the same is not true for the .readthedocs.yaml. There is no easy way to simulate deployment and that hardcoded Python version, looks exactly like the thing we will forget to change in a future upgrade. Implementing the proposed changes would just increase maintenance time substantially.

I would resist the urge to make any more changes, other than setup.py, setup.cfg and pyproject.toml (and versions). You can open a separate issue for the readthedocs and what improvements it adds to the documentation (I am not overly familiar with it's features).

FYI the sphinx docs Action is the recommended route according to the documentation. When ammaraskar/sphinx-action stops using requirements.txt, that would be a good time for us to switch too or basically whatever sphinx says is the prefered way to deploy on gh-pages.

[ZedThree]

Ah, apologies, I had assumed the project was already using readthedocs and the GHA here was just for testing, so I was just intending to add some config! I'll revert that commit and add a pre-build-command: pip install .[docs] to the action.

[gnikit]

No worries, I use the sphinx readdocs theme (which I might change to puro) but not readocs itself.

add a pre-build-command: pip install .[docs] to the action.

The Action runs from within docs directory so you will have to do a relative import. That said I don't see a reason why change the docs requirements.txt. To build docs you still need to cd into docs and call make html so I would keep all the dependencies within one dir.

[ZedThree]

The docs action should work now! It turns out the action hasn't been maintained for some time, and it has a few bugs. Notably that the image it's based on is very out of date which uses a version of sphinx incompatible with some of the docs dependencies. Switching to the sphinx-toolbox fork, and bumping the required version of sphinx fixes that.

While cd docs; make html will still work, with all of the dependencies now specified in setup.cfg, it's now possible to do the following in a fresh environment:

pip install -e .[tests,doc]   # Install all dependencies for building, running, testing, and docs
pytest --cov=fortls           # Run tests
python setup.py build_sphinx  # Build dosc

[gnikit]

Let me know when you are happy with this

[gnikit]

@ZedThree is this ready to merge? If so could you enable the option for me to push changes to the branch, otherwise I will have to cherry-pick into another PR. Either way is fine by me

[ZedThree]

Yep, ready to merge. I've merged in dev to fix the conflicts. It looks like I can't give you push access because the fork is from an organisation rather than a user account.

[gnikit]

Okay don't worry I will cherry-pick your commits into another PR then. BTW I was thinking something like this about setuptools_scm_git_archive since we will only be making use of it when installing straight from the repo

[gnikit]

Fixed in #44