I played with the CI a little and concluded that the following is the best:

Currently, the test is never executed in CI (tox) because pytz is never installed - I added it as one of the django42 dependencies, so it should now get executed with that one.

Also, I split the skip into two - now I get the original message with Django 5.0+, and "pytz is not available" when testing against Django 4.x without pytz.

If using pytz with a specific version of Django is a common enough thing that we need to test, I think that "pass the test if a dependency is missing" is an anti-pattern. +1 for adding it to the dependencies, -1 for the "skip if not pytz".

That is certainly true for CI here, but I can imagine somebody who uses Django 4, doesn't use pytz (it's deprecated there and not necessary) and who wants to run django-rest-framework test suite to ensure that everything works - this skip is there for those.

doesn't use pytz (it's deprecated there and not necessary) and who wants to run django-rest-framework test suite to ensure that everything works - this skip is there for those.

I'm missing the case here. Let's say someone forks the repository, makes some changes to it, and wants to run the test suite. They will run the test suite as a whole and that's all *. I can't imagine a case that could end up with "Oh I don't need pytz so the repo I'm contributing to shouldn't test it either."

* This is already automated and handled by the CI.

It's our case. We download django-rest-framework source, build it, make sure that it works with Solaris and then package it such that it's installable via our package manager (the same will likely apply to many Linux distros). One of the steps is to run the test suite.

We execute the test suite with pytest and thus use dependencies installed on the build machine - if you use tox (or anything else that isolates the test execution in a new virtual environment where it installs all the dependencies), pytz is always brought in, so this wouldn't matter.

But testing against the machine installed bits makes sense in our case and if we for some reason stop delivering pytz (it's not really used today as most libraries moved to native tzinfo), we would still want to make sure django-rest-framework works without it and this skip would allow us to do so.

All that said, I don't really have a strong feeling about this and I am happy to remove the skip :).

@kulikjak Oh, thanks for all the details. In general, my main assumption is that all contributors should work with the same standardized environment. Custom redistribution is an interesting case that I hadn't considered, but I'd expect to have an active fork in that scenario. All in all, I was more interested in understanding why it's needed, and I also don't have strong opinions about it.

Custom redistribution is an interesting case that I hadn't considered, but I'd expect to have an active fork in that scenario.

I agree, and we sometimes do modify sources slightly in cases exactly like this one.

But you are right that contributors here should not skip the pytz test, so I removed it.

(when I remove just the skip, the base and dist targets fail as they are executed with Python 3.9. I can add pytz as a dependency to those two as well, but placing it in requirements-testing.txt seems cleaner - all Django 5+ targets will skip the test anyway. Alternatively, CI can be probably modified to execute base and dist with 3.13).