This issue is a follow up / postmortem on PR #1594

Considering this PR has been unmerged and blocked by dependency hell since January, and no one has been able to properly use strawberry with recent versions of Starlette, I think you should reconsider your current CI tooling. It can be quite frustrating for contributors and users alike when issues are unfixed because of workflow issues, not because no one has tried.

I would highly suggest you use independent environments for integration testing with external libraries. It would allow you to much more easily test these without having to worry about conflicting dependencies blocking features and patches.

The other issue I see is that you now have 2 distinct versions of starlette that you could continue to support, but without regression testing older versions are more likely to break and not be noticed. “Most” package maintainers try to do matrix based testing where they test against an array of versions of other packages, and against an array of python versions as well.

To that end, I would suggest you use tox as it seems to be the tool of choice for package maintainers. It’s very simple to separate your tests into suites by folders, and have each test suite run in an individual environment with isolated dependencies. (Similar tools exist that I don’t have much experience with, see nox and thx)

As an example, we maintain a lengthy and complex tox.ini for New Relic with a long comment explaining our naming conventions at the top. There are much simpler examples in the tox docs that are enough to try the tool.

If you decide to use tox I’m happy to contribute or review designs, suggestions, and PRs.