Update dependencies

[eemeli]

Maintentance-y updates to the tool configs and CI actions, adding top-level dev-requirements.txt and pyproject.toml.

After merging, I intend to push a couple of commits directly to main applying isort and black to the codebase; they're left out of here as that'll touch pretty much all files.

The individual commits are intended to be relatively discrete steps.

[eemeli]

@eviljeff, would you have the bandwidth to look at this at some point?

[eviljeff]

@eviljeff, would you have the bandwidth to look at this at some point?

@KevinMind would be good for this, and has volunteered to take on the review, if you can give him the necessary reviewing permissions

[KevinMind]

I don't see anything in particular that would stop me from approving. I did find a few areas where you could consider performance impact and there are some other quick wins you can add here to make the workflows more composable, concise or run faster in general.

[KevinMind]

Seems like there are many python versions in use across the different jobs. If this is intentionally, adding a comment specifying an issue link or reason why a particular version is required will make someone (maybe you) reviewing this yaml file in 6 years very appreciative :)

If otherwise you don't need different versions you could pin the version using an environment variable and specifying this across the different jobs. This is just a suggestion.

env:
  - PYTHON_VERSION: "3.10"

jobs:
  lint:
    ...
    with:
      python-version: ${{ env.PYTHON_VERSION }}

Even in a scenario where you need specific versions per purpose, using a variable can also help encapsulate that purpose.

env:
   PYTHON_VERSION_ WITH_SPECIFIC_FEATURE: "3.6"

[eemeli]

Much of that range is due to inheriting a spread from before. The 3.12 for lint is just the current version and could probably be dropped to rely on the default provided by ubuntu-latest; baseline uses 3.6 because we still claim compatibility with that, and documentation's 3.9 is slightly arbitrary, but I'm loathe to spend many cycles on it given the doc build's complexity.

[KevinMind]

You explained it excellently just now. I Just wonder if pulling that information out of this comment thread into the action definition would be helpful for someone like myself reading the code for the first time without context. Just a light suggestion to do with what you think is best.

[KevinMind]

Can you use setup-python@v5 here?

[eemeli]

Dunno, didn't try. I intend to re-refactor this soon after landing this PR, by incrementing the minimum to around 3.9, which will let us get rid of this ubuntu-20.04 runner as well. The action versions will get updated at that time as well.

[KevinMind]

👍

[KevinMind]

I guess one consequence of merging the linting jobs on the GHA level is that if there is an error installing fluent.syntax you will not know if there would have also been an error in fluent.runtime.

Previously being in separate workflows would have revealed this as they could run separately and in parallel.

Does this have a performance impact on the CI run time as well? Have you considered a reusable action for setting up the environment that can then be shared across many jobs to allow centralizing configuration while still parallelizing execution?

[eemeli]

Eh, sure, but at the cost of additional complexity and interdependency. I'm trying to keep these actions simple, and tbh I'm not too worried about one error potentially masking a later error, given that it'll be revealed after fixing the first one.

[KevinMind]

I would be super peaved if I spent a bunch of time fixing one error only to reveal another that could have been known before, but I understand there are tradeoffs. Just wondering if you thought about it.