Readme badges and pyproject cleanup

[martinhoyer]

I'm not a friend with rst and have more experience with markdown. Will this render ok on PyPI page and other places? We also need to deal with man generation I presume?
PyPA should be ok based on:

$ twine check dist/tmt-1.40.0.dev2+ga31e8651-py3-none-any.whl --strict
Checking dist/tmt-1.40.0.dev2+ga31e8651-py3-none-any.whl: PASSED

github would look like this:

In pyproject, I've replaced Python 3.11 with 3.13 and removed the unmaintainable comments of what versions are available where.

Pull Request Checklist

• implement the feature

[martinhoyer]

Needs consensus on what badges are actually useful (which once to pick) and which of those make sense for them to be dynamic (versions, build successful).

I would say that Copr can be renamed to "Development/nighly builds" and just point to teemtee/latest, for example.

[happz]

Needs consensus on what badges are actually useful (which once to pick) and which of those make sense for them to be dynamic (versions, build successful).

I would say that Copr can be renamed to "Development/nighly builds" and just point to teemtee/latest, for example.

I'd probably drop "ruff" and "pre-commit", the rest will lead a user to some artifacts or docs, while these two are more like a statement, "yup, we test it", and we don't expect these to ever be red for main branch, correct?

[psss]

I'd probably drop "ruff" and "pre-commit", the rest will lead a user to some artifacts or docs, while these two are more like a statement, "yup, we test it", and we don't expect these to ever be red for main branch, correct?

Agreed, I feel it the same way.

[psss]

Let's use the fresh copr link.

[thrix]

@martinhoyer why to drop these comments? seems till useful ?

[martinhoyer]

@thrix Well, it seems unmaintainable, definitely was a mistake to add Fedora versions there. Mea culpa.

I presume we can add "explanation" for the lock, like "version xyz available on epel9 [04/2015]" or something", but not sure if there is any value as that is the case for all of them: "Min versions are dictated by minimal versions of RHEL/EPEL9 because we don't have something like #3605, this is also why we have Python 3.9, even though it will be EOL in 6 months"

[martinhoyer]

just realized they are also copy-pasted to .pre-commit-config twice.

[thrix]

@martinhoyer I believe this is a significant change, it would desire it's own MR, ideally with the pyproject.yaml changes. Seems to be now hidden, I need to read the comments to find out.

[martinhoyer]

@thrix hmm, afaik this is not being used in any pipeline and only affects hatch run test:foo, isn't it?

[martinhoyer]

I'd probably drop "ruff" and "pre-commit", the rest will lead a user to some artifacts or docs, while these two are more like a statement, "yup, we test it", and we don't expect these to ever be red for main branch, correct?

Agreed, I feel it the same way.

@psss @happz I don't see what's wrong with that. It just tells people that this project uses pre-commit and ruff, which can increase the respect for the project, making them more likely to get involved. I mean, it's literally called a "badge".

Alas, removed as requested.

EDIT: oh and it can remind people to run pre-commit install. I tend to forget in new repos ;)

[martinhoyer]

The dependency version bumps shouldn't make any difference in theory, but just to be safe, added full_test label

[mcasquer]

@martinhoyer LGTM, just a thought: do you think we can point the python-versions badge to a different place than pypi? IMHO some place in the docs would be better although I haven't found anything apart from a brief mention in the Unit Tests section

[happz]

Seems to be rendering well in both HTML docs and man page: neither of these two shows any sign of badges :/ Which I guess is fine, yet a bit surprising.