DevOPs improvements

[JPchico]

I was looking at the code and I think that something that could be useful would be to add a couple of DevOps improvements to make the code a bit easier to maintian.

I was thinking something like this:

• Change the installation to make use of the pyproject.toml one could add all the setup dependencies and so on there. This makes the configuration easier to maintain as there is only one file where everything is placed.
• Adding a .pre-commit-config.yaml this can help to make sure that the code styling is kept and if one chooses the appropriate linters it can even help to find bugs:
  • Ruff as the linter + mypy to ensure that there is type safety. I think that this can help with code quality and standardization.
• Adding unit tests that are run via Github actions to ensure that no bugs are inadvertently added
• Adding dependabot to update the dependencies if the tests pass.
• Adding pre-commit.ci to help check the code formatting and solve issues automatically whenever possible.
• Add codeccov to measure what portion of the code is being checked by the tests.

What do you think @rartino ? Some of these are relatively easy to make, and I could help, but I want to know what you think, what the base branch for the PR should be and so on.

[rartino]

Thanks for suggesting these @JPchico! Yes, I absolutely would like help with this!

• To change the installation to make use of the pyproject.toml: sure! I haven't looked at our setup.py config in a long time; I can only see advantages with getting this updated to the most modern way to handle python installation.
• Improving the unit and lighter integration tests and set up CI to run them (run today with make tests) would be great. However, I generally like to keep the testing tasks split into a non-GitHub-specific part (that is as large as possible) as a makefile target make tests, and then embed in GitHub actions only: <install dependencies>; make <something>; <act on the return code>. That makes it easy to run exactly the same CI also outside GitHub:s framework. Today we keep our unit tests compatible with the standard library unittest module, which can then also run in pytest and tox. (If possible it would be nice to stay with a unit test setup that can run without external dependencies.)
• I'd be very happy to add some "pre-commit"-type linting, trailing white-space removal, etc. However, in a similar spirit as for the unit testing, I like the design of having a makefile target, e.g., make audit which runs linters etc. with non-zero return for failure, and then put that in a .github/workflows/<something>.yml job (unless you can point out major benefits of instead integrating with pre-commit which I may have missed.) The audit target can then split up into separate types of audits, e.g., audit_pep8 that can then be coupled with targets that modify the code to correct these failures, e.g., as we today have make autopep8 that fixes pep8 issues.
• codeccov would be nice as well (I suppose it could be done via a makefile target as well, running via e.g., codecov-cli, but given how non-critical this analysis is, it'd be fine to just add a GitHub action for it).
• Dependabot for dependencies would also be nice. (However, the dependency handling in httk is currectly an overcomplicated mess, it was trying to solve 2014-ish issues on that generation of super-computing clusters, and was thus created to have no required dependencies and its own framework for loading optional dependencies. A lot of httk still runs without anything but the standard library; so technically the py*requirements.txt are inaccurate and our whole dependency handling is due for a major overhaul for httk 2).

[JPchico]

• I think that most of the test and pre-commit stuff I handle usually via tox as you say would allow one to run in the same way in github and locally. It sadly is not always fool proof. Sometimes the environment locally is not exactly the same than in github (mostly if you have different python versions, etc). I normally like this since it is self contained, and more importantly the tests run every time a commit/pr is done, I guess it should be possible use the make file approach that you suggest but I would need to check how everything works.

• Okay, I think that in principle one can simplify things if one throws away the python 2 support, it is not supported anymore anyhow so I think that that should make things a bit simpler.

[rartino]

I normally like this since it is self contained, and more importantly the tests run every time a commit/pr is done, I guess it should be possible use the make file approach that you suggest but I would need to check how everything works.

Having GitHub run the tests on commit/pr is still the idea, just that we replace whatever test instructions we would otherwise put inside the GitHub CI workflow with just make tests or similar. The same thing for, e.g., linting: make audit runs all linters etc. and fails the CI if the code isn't linted. Then on PR:s one will get a "red light" if trying to merge un-linted code.

It sadly is not always fool proof. Sometimes the environment locally is not exactly the same than in github (mostly if you have different python versions, etc).

Indeed; everyone's local environment is different. So, what we've done in some other projects is to also provide a make docker_tests that sets up a docker container close to the GitHub environment and then runs make tests inside that container. That would be nice to have here as well.

With that said, the fact that make test runs in your own arbitrary environment I see more as a feature: It means any user can clone the repo and run make tests to make sure everything works in their actual "production" environment.

Okay, I think that in principle one can simplify things if one throws away the python 2 support, it is not supported anymore anyhow so I think that that should make things a bit simpler.

In one of our projects we actually still have some Python 2 workflows running on top of httk. Still, I'm fine that we re-do the testing infrastructure now to only work with Python 3, and the Python 2 support can be non-unit-tested going forward. Nevertheless, the plan is to avoid Python 3-only code in the core parts of the httk 1.` branch, and go for a Python 3-only httk 2.