Update Python to use UV for project managment

[RossSmyth]

Best reviewed by-commit

Update to use uv.

Why:

• It uses venv by default so using and building packages is always project-local
• Has a lock file so you shouldn't get any funny conflicts
• Blazing fast or something idk

I just think it's a more sane way to interact with Python projects.

Things done:

1. Bump minimum Flit to 3.2, this is the recommended (minimum) version by flit devs. Flit 2 has been unmaintained for a while now, and there's no real reason to support it.
2. Use the more modern pyproject.toml layout with a [project] section.
3. Add minimum version for the dev tools. Unsure what this project is using but I put in some values based upon some commit snooping.
4. Update the Makefile to use uv for working with the Python code
5. Update the github workflow to use UV

[RossSmyth]

@burrbull @LuigiPiucco are contributions accepted to this repo or is it just for rust-embedded people or what

[LuigiPiucco]

I'm not part of the project, just a contributor, like you. But as an outsider, I can recommend you to rebase your changes to remove the merge conflicts. Other than that, I don't think this repository restricts its contributions to the team, they've probably just been busy elsewhere. Now that you've pinged @burrbull, I think you will receive a review.

[therealprof]

@adamgreig Any opinions on this?

@RossSmyth Is the lock file necessary? We usually don't do those...

[RossSmyth]

We usually don't do those...

Then how do you ensure that your end users have a consistent experience?

Oh I did not realize there isn't a Cargo.lock file. That is not very good practice for an end-user binary imo. I always install everything with cargo install --locked because it is important to me that I am using tested software, no just random versions of dependencies that may be broken.

[RossSmyth]

And of course I do that with software I supply to my customers. I bump the lock files every Sunday and then commit them automatically if CI passes.

It is about making sure software actually works, and the UX is consistent.

[therealprof]

Then how do you ensure that your end users have a consistent experience?

If the software breaks then someone has done a bad job at doing proper semantic versioning -- happens, but so rarely that it's really not worth worrying about. I'm much more concerned about the maintenance overhead of having to manually bump versions constantly or trusting an automatism to do it and needlessly cluttering the software history with bogus commits.

YMMV, of course.

[RossSmyth]

semver isn't a thing in the Python ecosystem like it is in Rust. And also people do break things accidentally.

[therealprof]

semver isn't a thing in the Python ecosystem like it is in Rust. And also people do break things accidentally.

Fair. But your assertion was that this is also necessary for Rust to ensure a consistent experience. 😉

Mind rebasing so we can give this a go?