Modernize project configuration

[alexandrehassan]

As mentioned in the python packaging docs using pyproject.toml for some of the fields that are currently in the setup.py is recommended.

On top of the mandatory sections:

• .coveragerc can be included
• requirements.txt has a section
• requirements-dev.txt (depends on the tool).
• setup.py (depends on the tool).

This can all be done without changing away from setup tools, UV is what seems to be used as the new standard.

I'm currently playing on it, but I'd be happy to hear any feedback

[fliiiix]

The biggest hold back is/was the debian support for PEP 517, this package right now should still build on Debian 11 Bullseye (i would need to take an other look a quick google showed it might be possible), also there is still Python 3.7 support which might complicate things

In general here is an other more modern project i did: https://github.com/fliiiix/pandoc-d2-filter/blob/main/pyproject.toml and probably radish should also go into this direction

[alexandrehassan]

I'm pretty sure we were using radish in a bullseye container alongside pep 517 packages. I'll try and include some kind of way of automating this testing.

[fliiiix]

The problem is not to run it alongside, the problem is to create a radish-bdd debian package, which as far as i can see requires https://packages.debian.org/bookworm/pybuild-plugin-pyproject which is only available starting with bookworm 🙈

[alexandrehassan]

I'm not sure I understand, are you saying to build a .deb package? I can't find any mention anywhere in the docs or the repo of installing any way that isn't pip. Installing via pip seems to work as long as you use a version of pip that supports PEP517. I'm pretty sure pip supports 517 since PIP19 (2019), that was released shortly before python 3.6.

Ideally you can keep supporting every python version, but python 3.9 is now end of life, so I think if 3.7 is the only thing that is blocking modern tooling, dropping support for it would not make you any enemies.

[fliiiix]

I'm not sure I understand, are you saying to build a .deb package?

Sorry for not making this clear enough, I am still maintaining this because we use it internally, where for various reasons radish is repackaged as a Debian package. (And to be honest I don't recommend to repackage it for Debian 🤷) And because of that I'm holding back with modernization that would hinder the internal fork that needs to be packaged as debian package.

I think/hope i can move to Bookworm somewhere Q1. (I will check on that again internally)

What are the benefits of migration you see?

[alexandrehassan]

It makes sense now, that's one nice advantage of having the main maintainer working for you! I'll see if I can work a way around it.

For the advantages of modernization I think the big advantages is it makes it easier for people to contribute, most modern projects use some kind of dependency manager and the pyproject.toml is now supported by most of the tools this project uses. Using a dependency manger would make building and publishing slightly easier. UV specifically also makes installing dependencies really fast.

I wouldn't ask you to do this since your time can be spent somewhere else for greater benefit. This issue is more of a way for me to gather requirements to make submitting a PR easier.

As of now I have:

• [x] No preference on build tool (I prefer UV so I'll go with this).
• [ ] Ideally would provide some way of building a deb package with bullseye as the target.
• [x] Should ideally support the full range of python versions that are currently supported (3.7-modern),
  • [ ] Ideally we can narrow this range a bit (3.9-modern), but if you internally use a 3.7 I can add that in
• [x] Document the changes to the workflow
  • [ ] Build/publish pipeline
  • [ ] (if possible) debian build instructions
• [x] I noticed that you have a tox file, but it isn't included in the test instructions or the pipeline, I'll try to add that in
• [x] The requirements are currently really narrow, once I have tox working I'll try and broaden them a bit (especially dev ones)

Let me know if I'm missing anything (and if you can confirm the python version range that would be really useful)

[alexandrehassan]

https://github.com/alexandrehassan/radish/actions/runs/19251063198

With the pyproject I was able to run the tests for the full matrix (3.7-3.14) excluding windows3.7 (this is a separate issue with this exact combination of things that cause uv to crash.

I did look into the debian 11 and couldn't find a work around. Once I get your feedback about the above I'll go ahead and create a MR but as of now most of the work is done.

[fliiiix]

Ok i guess lets do it 👍 the list looks fine to me if we break the debian build i will backport fixes we need internally and we move forward here

since even debian 11 has Python 3.9 i think it would be fine to support 3.9 as oldest version if the effort is to big