Puts requirements in pyproject

[purepani]

This just puts the requirements into pyproject statically, as opposed to dynamically defining them with setup tools.

[purepani]

Ok it looks like I have to fix the CI to do this. This is definitely worth doing, but was a bit more effort than I was expecting

[FoamyGuy]

I don't think we would want to make this change to only a single repo. Ideally the actions config should stay in sync between all of the circuitpython library repos.

I don't necessarily think we would want to move the requirements into pyproject.toml either. I believe that some of the infrastructure utilities in use will expect that requirements.txt exist and contain the required libraries.

I'm not sure that I see the up side to moving them out of requirements.txt and needing these news actions requirements and steps. Can you say why this is approach is better than what we have currently in place, or what problem it's trying to solve to switch it?

[purepani]

I don't think we would want to make this change to only a single repo.
Yeah that's definitely true. If this were to be changed, it should be across all the libraries.

I didn't have a specific problem in this case, but in general static configurations are "better" as they're more in-line with modern python packaging. Tools will generally support the static configuration natively (for example something like adding a dependency through the cli, or exporting groups of dependencies in an export format like requirements.txt together).

This was definitely just a knee-jerk reaction to seeing that those were defined dynamically, and that my default position is "static definition through pyproject unless there's a good reason not to."

One problem I do have is I personally generally use uv for projects, and that doesn't support dynamic dependencies for venv creation. Granted, this is definitely a me problem, and is pretty easily solved in my case(and I do think supporting venv creation through uv with dynamic deps should be a uv feature), so I don't really consider this a circuit python problem per-se. However, it is an example of tools being better supported for static configurations. Also uv can install from a requirements.txt; it's just ever so slightly more annoying.

As you said, this should probably also just be done through the GitHub actions upstream.

I don't think it would be too hard to add this to the upstream actions and do change this incrementally across all the libraries as they have time to update, since it's pretty easy to export a requirements.txt file with pip for both optional and required dependencies.

TLDR: More tools are supported with static configs, so dynamic dependencies should usually be an escape hatch when needed, at least in my opinion. Probably not a big need to change it, but it's probably a good idea to do so. This should probably be done in a PR upstream.

[purepani]

To reply to this:

I'm not sure that I see the up side to moving them out of requirements.txt and needing these news actions requirements and steps.

I would argue that the tools should be updated to also support pyproject.toml dependencies, since that is standard, but certainly I don't know how much work it is to do that, and it certainly might not be worth it.