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.

[tekktrik]

Hi y'all! I was looking through open PRs and saw this one, not sure if there was more discussion after this.

@FoamyGuy is correct in that much of our infrastructure expects this current state across all the libraries. Primarily, automated library checking tool (adabot) would almost certainly need updates, as well as the cookiecutter repository used to make new repositories, as well as patching the old ones en masse. The first and last ones are probably the most difficult, I think.

Based on work I did to move the libraries off of setup.py and into pyproject.toml, I don't think getting those ready via the adabot tools will be wildly difficult, but worth discussing since it's a large task that affects the entire infrastructure. If that's the direction that others are interested in moving toward, I'm happy to start working on that.

[purepani]

Yeah there wasn't more discussion, and least from me. I'm not super active here, so my opinion on what y'all should do is very much backseating the project, but in general I think it's a reasonable recommendation from me to try and move infrastructure towards more modern python standards of the will to do so is there.

That being said, this should probably be an iterative process rather than a "do everything all at once" project since there are so many things to change
So with that in mind, there should probably be a transition period where the tools you use experimentally support pyproject.toml and requirements.txt at the same time, and new projects can use the pyproject.toml when all the infrastructure ends up supporting it, and only then does should a migration to old projects start.

To me, someone who doesn't have intimate knowledge of the situation here, that seems to be the best path forward without causing a huge disruption. I personally would recommend this be done, but again, I'm not really a stakeholder here, so that should definitely be done only with more discussion.