BrianGelhorn/DevEnv-Doctor

DevEnv Doctor feels like a useful, tightly scoped CLI for a problem many Docker-heavy projects have: setup failures that only become obvious after a developer has already spent time trying to boot the stack. I like that the README quickly explains the purpose, then backs it up with practical usage examples for checking the current directory, pointing at a custom Compose file, filtering by severity, and generating JSON reports. The exit-code behavior is also a strong choice for adoption because it makes the tool usable in CI rather than only as an interactive helper.

The project structure is clean for a young Python CLI: src/devenv_doctor separates CLI handling, check orchestration, and individual Docker/Compose/environment checks, while the tests directory covers CLI, runner, Docker, environment, and Compose behavior. The pyproject.toml is straightforward, with Typer, PyYAML, python-dotenv, pytest, and Ruff, and the GitHub Actions setup runs both linting and unit tests. That gives the repository a more finished feel than the 0-star count suggests.

The biggest adoption gap is packaging and trust signals. The README says to download a Linux AMD64 binary from GitHub Releases, and there is a v0.1.0 release, but I did not see a license, contributing guide, or deeper security notes around running diagnostics against arbitrary projects. Since this is a tool that shells out to Docker and inspects local environment files, even a short “what this reads / what this does not upload / what commands it runs” section would help users feel safer trying it. A few sample failing Compose fixtures in the docs would also make the rule engine easier to understand at a glance. Longer term, the README’s future direction around expanded Compose analysis and readiness scoring is the right place to go; I would also consider documenting how new checks are added so contributors can extend the rule set without having to infer the runner contract from code.