Fix bug in temporary path setting (was: Clear up cache-related warnings on Windows) - #9703

OK now that's really weird - non-data tests, astropy/visualization/wcsaxes/tests/test_images.py::TestBasic.test_contour_overlay are using the temporary cache created for tests in test_data.py: /tmp/pytest-of-travis/pytest-0/test_cache_dir_is_actually_a_f0/file/astropy. The temporary cache setting should be going away as soon as the test is over, it's established by a pytest fixture in test_data.py.

The fix for #9704 would be much clearer (and in fact the bug would not have arisen) if the context managers had been written as generators with @contextlib.contextmanager but they store data globally on the class object so it's a little weird, and they use inheritance, which is awkward to replicate with functions.

Lesson: don't use explicit __enter__ and __exit__ unless you absolutely have to.

@bsipocz - should I zap the changelog entry then? This does actually fix a bug in astropy.config.paths. maybe I should update the description too?

Yes, the current one has to go as none of that is user facing. However, I'm not against adding one for the config part.

But, let's wait for @pllim's review.

Sorry, this is on my list to review but I am catching up with post-gobble-gobble email pile. 🦃 😬

I can confirm that this PR clears the warning I saw in #9634 🎉

Once @bsipocz gives instruction on how to proceed with the change log (and maybe squashing), this is good to go. Thank you very much!

Depending on whether this or #9669 gets merged first, the other will need a rebase to rerun the CI before merge, just in case.

Please rebase and let the CI run one more time now that #9669 is merged. Thank you!

One of the job failed with some cache error. I restarted it in case it's transient.

Still failed. @aarchiba , any ideas?

astropy.utils.data.CacheDamaged: Apparently abandoned files: {'C:\\...\pytest-0\\test_check_download_cache0\\astropy\\download\\py3\\709c583b30be1ba30dab6b73157c9610'}

I manually deleted Travis cache for this PR and rerun the failed job again. We'll see.

Tests passed. @aarchiba , is that CacheDamaged error earlier of any concern? Or can we merge this?

I don't think the CacheDamaged is real - I mean it shouldn't happen, but I didn't change anything relevant to it, and it went away on a clean rerun. And the failure mode is that there is an unreferenced file left behind, which is a less-serious sort of error. I don't know where it came from. But the state of the code previous to this fix introduced some nasty dependences between test cases.

Okay, merging then. Thank you very much!