2026 Revival / Tidy project

[phalt]

I am embarking on a project to update the PokeAPI source code

⚽️ Goals

1. Make PokeAPI use modern Python tooling and be easy to maintain.

• Update the Python tooling to use modern Python project tools like uv, ruff and ty.
• Fix all formatting issues in the project so that ruff passes without failures.
• Fix all typing issues in the project so that ty passes without failures.
• Re organise all the tests into logically separate files.
• Add testing coverage reporting.
• Extend the tests.
• Ensure 90%+ code coverage.
• Enforce code coverage in pull requests.

2. Prepare PokeAPI for the future

We don't actually run the live Django server in production, so what is it useful for? I want to reevaluate the tooling we use to create the API and make sure it is suitable. I want PokeAPI to still be working in 20+ years time.

So far my gut feeling is that boring tools like Django are good for this, because even at 10+ years old the project still works, and that cannot be said for a lot of other software out there. Also, Python itself is really easy to pick up and understand. So I am thinking that I will keep it as Python + Django, but I may look at reducing dependencies or even considering an alternative to Django REST Framework (which is currently "feature complete" and will never be updated again).

3. Figure out how we deal with AI contributions

This project has an interesting positioning in the world of Open Source Software. It is a "toy" project and a learning resource for most - so it exposes itself to a lot of younger, fresher, enthusiastic devs who want to learn how to program and contribute. We need to understand the risk with AI contributions from more junior engineers and the risk of overwhelming us (the maintainers) and turning this into a slop fest.

4. Tidy issues and Pull Requests

Some of it is duplicated, some is no longer true. Most of it is out of date. I have a radical view of issues: if they're genuinely a problem then they'll re open them.

I am very tempted to close any issue and PR that hasn't been updated in a year. All issues can be reopened if it's genuinely important so we don't lose anything.

Most issues could also just be discussions (and I'm happy for discussions to operator like a forum), which leads nicely into...

5. Make it clear we want contributions, not error reports

Nearly all issues are "this data isn't here" and we reply "have you considered adding it?" Or something to that affect. We are not paid to maintain this, and most of the time contributions can and should be done by issue reporters.

6. Other small goals

• Add a cli to replace the build_all steps that currently require starting a shell
• Review and update the pull request and issue templates

🚫 Not goals:

• Add a new API version in anyway.
• Change or modify the pipelines for generating the production API in anyway.

[phalt]

Part 1: UV and Ruff support