Developer tooling consensus

[lfse-slafleur]

Hea everyone!

I have been seeing some movement on s2 repo's regarding developer tooling and more importantly, divergence. Different ideas floating around and everyone wants to use what they are used to. Personally I set everything up with pip-tools because of its old-school simplicity and single-use instead of 'one-stop-shop' tools like poetry and uv which may require a system install outside of the virtualenv (or some manual manouvering of activating your venv manually).

The main gist that I am seeing is people want to move toward something like poetry and uv which is fine by me. But I want to settle on one set of tooling that is used in all repo's instead of having each repo work slightly different.

So lets kick-off with me proposing a list that is going to create discussion and lets settle on something. Be warned that the argument 'but that is what I am used to using' or any variation is not going to hold any weight because we are asking a part of the community to switch nonetheless. Arguments e.g. 'uv is faster than poetry in dependency locking' or 'poetry is a bit older and has more adoption' are perfect arguments.

I reserve the right to make a choice in a stalemate or inactivity due to: 1) I started this discussion and 2) moving away from pip-tools hurts my techy heart but I will survive xD.

So some guidelines from my end:

• Allows adoption by the whole community.
  • Needs to work on Windows, Linux (Fedora, Ubuntu, Debian, Arch) and Mac.
• Simple to use.
  • If a tool requires a command e.g. pytest -k some.really.long.path:here instead of pytest in order to work, that is less preferable.
• Stable
  • Lets not switch every 6 months.
• Needs to work in CI
• Faster execution == quicker feedback == preferred but 0.1 sec or 0.5 sec is insignificant so that both counts as super fast.

Hope this helps to get to some kind of consensus and we can all be relatively happy techies and focus on the software.

So without further ado, the list:

• Linting: ruff
  • Ruff is faster than pylint and can fix a bunch of stuff instead of only complaining
• Typechecking: pyright AND mypy
  • There is a difference in these typecheckers and we need to keep both happy so our users can use either.
• Testing: pytest
  • Only one I know of that works and is widely adopted. If you guys have a different candidate, please propose.
• Versioning: setuptools-git-versioning
  • Git tag versioning instead of having to manually alter a file.
  • Saves time by not having to update a PR with a higher version number if someone is just a bit quicker with merging. Also saves on having to reapprove a PR because it became stale due to change in version number.
  • Also we can release or not-release when we want instead of releasing after every single change. Saves time for our user who have to keep their versions up-to-date and gives us control on which fixes we want in which release.
• Releasing: Pressing the release button on Github which leads to a tag that setuptools-git-versioning listens for.

[lfse-slafleur]

@dolfandringa @philipptrenz @jorritn @wcoenraads @victorgarcia98 @Flix6x Pinging you all for this discussion. Please ping anyone else relevant and feel free to chime in on the discussion.

[wcoenraads]

I personally like uv, because anecdotally it has been the tool that has delivered me the least problems. ;) It's fast and doesn't require me to keep a list of virtual environments, I can just do uv run and it works. Using a different tool is also fine, I usually set up my own uv configurations for those projects anyway.

For the other tools (linting, typechecking) I defer to the people who develop in Python more than me.

[dolfandringa]

I would either use uv or poetry, as they are both swiss army knives that solve the same problems. I haven't used uv but it seems to be popular so I'd like to try it out.

For linting and related stuff I'd choose to use ruff. It replaces isort, black, pylint and flake8 into a single tool that does all of it. It is also much faster as it is written in rust and integrates well with IDE's for auto-formatting and such. It is also highly customizable but comes with sane defaults, so you can just slowly add changes as/when they are needed.

[dolfandringa]

Typechecking: pyright AND mypy
There is a difference in these typecheckers and we need to keep both happy so our users can use either.

I disagree here. There is a difference between what people choose to use for type hinting and code completion in their IDE, versus what is used as the source of truth. Using mypy and pyright both potentially leads to conflicts between them, and it requires setting up rules and exceptions twice. I prefer pyright over mypy because its faster and doesn't require the plugin system from mypy that automagically defines types for untyped code with black magic plugins. But it does sometimes cause other issues where mypy's plugins allow you to deal with badly typed code magically, where pyright might not do it as well because it relies more on how it "should" work. But this is becoming less of an issue as time evolves and type hinting and standardization is becoming more common practice and the python standards become mature.
But I am cool with mypy too instead of pyright. I have both options in my IDE. But I'd choose one for official usage. If people then want to use another one in their own IDE, that is cool, but should be up to them to manage.

[dolfandringa]

Versioning: setuptools-git-versioning

I would stick to the newer python standards and use tools native to it. I know poetry does, and assume so does uv. Use PEP440 versioning, together with pyproject.toml to specify them (https://peps.python.org/pep-0621/ and https://peps.python.org/pep-0725/).

• Github actions can deal with automatically changing the version number, for instance when a branch is rebased/updated to the latest dev version to change the version number through poetry version [prerelease|patch] or the uv equivalent. We can also specify in the CODEOWNERS file that github actions is allowed to do this, and it doesn't require a new PR approval.
• Github actions can also automatically create tags on pr merge to dev/main and you can read the version number from the pyproject.toml to make the tag (poetry version or the uv equivalent). This makes sure we have version numbers in the python package we publish on pypi (from pyproject.toml) that automatically correspond to a tag, and reading and setting version numbers is automated.

Also, I see there is a version.py in the s2python repos. If we specify the version in pyproject.toml (long live pep standards) we could read the version number there with:

try:
    from importlib import metadata
except ImportError:
    import importlib_metadata as metadata

VERSION  = metadata.version("s2python")

to remain backwards compatible.

[dolfandringa]

Testing: pytest

I don't know of any alternative that is used commonly anymore.

[philipptrenz]

For us, s2-python ends up in our Venus OS, which gets built through OpenEmbedded (OE). uv is not (yet) supported by OE, so we highly prefer to either stick to pip-tools or go with poetry, which is supported.

Regarding everything else, we don't have any clear preference.

[jorritn]

The argument of @philipptrenz is important to me. So let's not move collectively to uv and becoming incompatible with pip-tools. Furthermore, IMHO it is more a matter of personal preference of developers which tools to use for dependency management as long as there is a standerd way in which the dependencies are locked, and that's a problem with Python as all tools that manage dependencies have their own lock files... but the generated dev-requirements.txt will do. And how to create python environments are also a matter of personal preference from my point of view.

Although I personally prefer uv because of it's speed, I think we should stick with pip-tools for a while because of compatibility. And with the generated dev-requirements.txt every one can still manage its own environment.

Linting, formatting, sorting etc. is another story of course, that should done the same way by everyone. There seems to be consensus on Ruff and that's fine with me too.

I don't have a preference for typechecking but agree with Dolf that if pyright and mypy are not compatible in all cases, we'd better just chose one.

[Flix6x]

Just to let you know I'm following this discussion, but am not strongly opinionated. @nhoening just pinging you in case you do have an opinion to share, as you made most of these types of choices for our repos.

[nhoening]

Good approach to unify in an eco-system, @lfse-slafleur !

For context, in FlexMeasures, we use pip-tools, black, flake8, mypy, pytest, setuptools_scm (versioning).

I believe we don't have very strong opinions. I believe all these tools do a decent job. Some are slower, so it'd be nice to be fast (uv) but no deal-breaker.

I am considering uv at the moment, happy to learn about Ruff, mypy I'd rather not change if not needed.

pytest has no challengers, indeed.