Update build and deps

[philvarner]

Related Issue(s):

• n/a

Proposed Changes:

1. Convert pre-commit config from using a separate environment that must be independently and duplicately maintained to using the local environment with the same dependencies as dev.
2. Add pymarkdown checking and reformat markdown files to conform
3. Change all primary and dev dependencies from caret to >=
4. Re-generate poetry lock from scratch
5. Update project description to match current acronym
6. Fix several typing deprecations
7. collections.abc.* -> typing.*
8. Dict -> dict
9. Type -> type
10. replace removed methods from pyrfc3339 between versions 1.x and 2.x with their equivalent code

PR Checklist:

• I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.

[tylanderson]

I know we've liked local pre-commit for dev, but they do not fully play nice with some popular tooling (aka VSCode), so I think it could be easier for new contributers to avoid dealing with

[pjhartzell]

@tylanderson Could you give a bit more context on the problems with a local repo for pre-commit? I feel like I've experienced issues with local pre-commit in the past (I also use VSCode), but I haven't had a problem with that in a while, so I'd benefit from a reminder on what they are 🙂 . I do remember problems where the tool versions specified in the pre-commit yaml (via remote repos) were out of sync with the same packages that were in my requirements-dev.txt: I'd end up where formatting with the version of ruff installed in my venv did something different than the version of ruff specified in the pre-commit yaml. I remember this because I still stumble across this problem in repos that do not use a local repo for pre-commit.

[philvarner]

avoiding having a version difference between the local venv (which is what vscode and I assume other tools use) and the pre-commit env was the intention with this. I haven't had any problems with this approach and VSCode, so also interested to hear about the problems.

[tylanderson]

@pjhartzell I believe this issue tracks the issue I had seen in the past, it's a bit non-obvious from what I remember.

I do agree that the benefit of catching formatting, etc early is nice.

[philvarner]

I think we should document that issue in the README -- I think having a consistent environment that doesn't have to be independently maintained and with possibly different default configuration is worth making it easier to use a single IDE that has broken behavior (at least as I see it).

[c-wygoda]

shouldn't these all include a "but less than next major" condition as well?

[philvarner]

I had to add it for python because some other package had that constraint, and it wouldn't build without also applying it to python.

The argument for only having a floor is that it's up to the downstream user to validate that it works with whatever specific fastapi/etc version they choose for their app, and that we don't want to unnecessarily restrict the version they can use just because we're not sure it will work. We're also not testing this but with one version of any of these libraries, so it's still not guaranteed that it will work with whatever version the downstream chooses even if it's within some reasonable semantic versioning constraints.

[pjhartzell]

It would be nice to have CI run tests on an install with all dependencies pinned to their minimum version and on an install with latest set of dependency versions that resolve. But I think that is out of scope for this ticket.