Ruff, Black, and others

[joaomcteixeira]

On a different note, i got rid of bumpversion and check-manifest in favour of setuptools_scm and replaced isort and flake8 with ruff and black over at https://github.com/coroa/python-project-skeleton/tree/use-automatic-versioning . Since this completely takes away your versioning workflow, i do not intend to PR the whole bunch, but if your interested in bits and pieces. Feel free

Originally posted by @coroa in https://github.com/joaomcteixeira/python-project-skeleton/issues/33#issuecomment-1438143611

[joaomcteixeira]

Hi @coroa,

I moved your comment here, so we can discuss it without overloading the PR.

I have been aware of black for quite some time. But I have always felt very comfortable with flake8 because I like tools to tell me what is wrong but not to correct things around automatically. So I have always preferred flake8 in that sense.

However, it's the first time I hear about ruff. I have walked around the project, and it looks pretty interesting. I am positive to add it here in the future, despite my love for flake8 and isort.

I think I will not adopt setuptools_scm in disregard of bump2version and check-manifest for now. I like bump2version and check-manifest simplicity and straightforwardness. So far, I need to see how setuptools_scm simplifies the process or improves readability. I may be missing something.

While I try to keep this project up-to-date, I am conscious that some tools come and go very fast. Therefore, I try to find a compromise also with long-term maintainability.

Let's keep discussing this, Cheers,

[coroa]

I have been aware of black for quite some time. But I have always felt very comfortable with flake8 because I like tools to tell me what is wrong but not to correct things around automatically. So I have always preferred flake8 in that sense.

Well, i have been contributing to a few projects where people did not care too much about following the same code style and the main strength of black for me is that it just standardised all these layout questions away. Some of it felt awkward in the beginning, but it all became familiar over time.

The auto-correct is what i probably like most about it. I hated it, when online stickler or some such complained and i had to decide whether to research the right ignore code or to format it exactly as it told me to. With black, i just press "Format document" and don't have to care anymore.

I think I will not adopt setuptools_scm in disregard of bump2version and check-manifest for now. I like bump2version and check-manifest simplicity and straightforwardness. So far, I need to see how setuptools_scm simplifies the process or improves readability. I may be missing something.

I am used to having control over whether to release something as a new version or not. Your workflow, where every PR merge into main releases at least a patch version workflow (unless explicitly skipped), seems to be too drastic to me. But it is also good to get quick pseudo-versions in between. With setuptools_scm the project version is automatically determined from the last git tag in your history. Main benefits, i would say are:

1. Easy to set-up. dynamic = ["version"] and build-requires = "setuptools-scm" in pyproject.toml is all you absolutely need, for it to set versions and fill up the manifest with all files in the repository. If you want a __version__ attribute, you need to add some 4 more lines to __init__.py.
2. New version, just means you add a new git tag (or use github's releases/new ui).
3. You get unique version strings for every commit, f.ex. 0.22.2.dev7+gbf18ac7f would be what you get by default for version tag v0.22.1 and then 7 additional commits to the sha gbf18ac7f.

Works well enough for me, anyway. I very much like how CHANGELOG.rst is built semi-automatically in your workflow. That's my biggest regret :).