Ran Benita

Are you reusing the test DB (keepdb) or creating it anew every time?

What you want to do is to run a step between when the DB is created and when the migrations run. The trouble is, that pytest-django (or really [Django itself](https://docs.djangoproject.com/en/3.1/topics/testing/advanced/#django.test.utils.setup_databases))...

Assuming that your production DB has already the schema created, you can just "cheat" and retro-edit it into your initial migration. That shouldn't actually cause any issues.

Can you provide a way to reproduce this?

Does your project use multiple databases, or creative fixtures involving the database?

`http::Uri` actually parses HTTP request targets. If I'm reading [the RFC](https://tools.ietf.org/html/rfc7230#section-5.3) correctly, the character `"` is not a valid character in the `authority` part of an absolute-form HTTP request target....

As far as I understand, this is not strictly speaking a valid HTTP request target (you can start tracing from [here](https://tools.ietf.org/html/rfc7230#section-5.3)). As I understand it, the correct way to write...

Interesting. The "exception-in-finalizer" problem is a classic issue with excpetions. The two approaches I'm aware of are indeed either to suppress or crash. Python itself chooses to suppress with a...

My opinion on the current PR is that it's problematic. In https://github.com/pytest-dev/pluggy/pull/257#issuecomment-619588937 @maxnikulin nicely explains their point of view - that the hookwrappers are analogous to nested function calls, and...

I should note that this PR is definitely an improvement on the *current* pluggy, because current pluggy also propagates, but just doesn't do proper teardown, from what I understand. But...