New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
disable cache for all tests except test_cache.py
and benchmark tests
#886
Conversation
test_cache.py
tests
test_cache.py
teststest_cache.py
and benchmark tests
@@ -7,7 +7,10 @@ | |||
import cloudpickle | |||
from diskcache import Cache | |||
|
|||
_caching_enabled = True | |||
if os.environ.get("OUTLINES_DISABLE_CACHE", "") in ("", "0"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need an environment variable for this?
Also, can't we use the existing disable_cache
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be beneficial to introduce an environment variable that allows users disable cache, even outside of pytest.
I could also simply make the disable_cache
fixure patch this variable and have no changes to caching.py
if we don't want to expose this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To move this forward, we need a description of the approach and some justification(s) for why we should (or need to) use it over the alternatives (e.g. see the approaches in the test suite).
We need a general solution that is applied to all test cases in I agree about the environment variable being a problem. The cleanest solution is to clear the cache before each individual test run. This won't require any special handling for benchmarks or |
Clearing the cache is another necessarily "global" approach with similar drawbacks. Ideally, we would have something that works, still allows the tests to be run in parallel, and introduces a minimal amount of new code/logic (even if said code can be multi-purposed). |
Thanks for reviewing. Indeed, we want to ensure the code remains robust. I'll close this for now. |
Fixes #853