Charlie DeTar

Very intriguing! Thanks.

Hitting this as well. It appears that fixture data loaded in `django_db_setup` gets removed for all subsequent tests by a test that runs with `@pytest.mark.django_db(transaction=True)`. We're loading fixture data in...

Thanks for the suggestions @blueyed. I tried adding this definition to `conftest.py`: ``` import pytest from django.core.management import call_command from pytest_django.fixtures import transactional_db as orig_transactional_db @pytest.fixture(scope='session') def django_db_setup(django_db_setup, django_db_blocker): with...

No change... with only the `transactional_db` override in conftest.py, the fixture was unavailable to regular `@pytest.mark.django_db` tests (without `transaction=True`), no matter what order they run in. With both the `transactional_db`...

This can be done using the built-in dumpdata by passing the `-a`/`--all` flag: ``` ./manage.py dumpdata --all myapp ``` That causes dumpdata to use the base manager rather than the...

It seems to me that the solution to this will cover a lot of the same territory as #103 (subresource integrity support). Both will require addressing the content of assets,...

One more data-point: excluding using `--exclude-from=` rather than `--exclude=` works as expected. Looks like there may be something in the way rsync is invoked with the flags that causes `--exclude`...

We're also impacted by this -- we're unable to make test payments. In Firefox, after loading another page, we get the following error mesage: Notice: Trying to get property of...

Pardon my error; we were running 4.4-1.7, so this was properly in issue #27 not here.

Why does that feel better than the modal? You could be right, but my intuition doesn't at the moment find an advantage to always-on response fields.