fix download_zip

[akaszynski]

PR #2727 introduced a breaking change to our downloads module CI/CD is failing. It should have bumped the cache version in that PR and discovered the flaw with the PR.

Turns out there's an edge case that #2787 didn't consider with a fresh cache: a zip file (without extension) that's the same name as a directory. For example, we have Ensight an Ensight.zip. If the Ensight directory already exists locally, our Ensight.zip won't be downloaded and PyVista will look in the Ensight directory. However, since it's a different directory altogether, the downloads module won't find the file it's looking for and will fail outright.

The fix for this is to simply keep the "zip" in the directory name. It will look a little strange, but this is good in two ways:

• Matches the directory structure of vtk-data better. Archives will simply appear as directories.
• CI/CD works again.

Recommend immediate merge to get this CI working again.

[adeak]

Go for it.

[akaszynski]

Go for it.

I'll merge if passing.

[codecov]

Codecov Report

Merging #2787 (f10ab81) into main (91a562f) will decrease coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2787      +/-   ##
==========================================
- Coverage   93.96%   93.90%   -0.06%     
==========================================
  Files          76       76              
  Lines       16292    16292              
==========================================
- Hits        15308    15299       -9     
- Misses        984      993       +9     

[akaszynski]

@adeak, this needs another look over. Turns out it's not as easy as a cache bump.

Tougher nut than expected

[akaszynski]

Turns out files are hard.

Had to handle another edge case where the retriever returns the exact same path as the requested filename. This edge case only occurs in testing, but I figure if someone wanted to implement a custom retriever for whatever reason in the future we should handle that as well rather than modifying the test.

[akaszynski]

Ok, ready to review. There was one final fix needed in bdd3248: our example was assuming paths.

[adeak]

I've pushed a few cosmetic changes (some unrelated to the PR), please check. Otherwise this LGTM, thanks

[akaszynski]

Your changes LGTM. As always, thanks for the attention to detail @adeak!

[MatthewFlamm]

Turns out files are hard.

Had to handle another edge case where the retriever returns the exact same path as the requested filename. This edge case only occurs in testing, but I figure if someone wanted to implement a custom retriever for whatever reason in the future we should handle that as well rather than modifying the test.

I'm fine with the changes here since it is all private methods, and as long as we play by our rules everything should still work. But, I think the testing is flawed. If I'm understanding the issue is that a zip file retrieved is placed into the examples path by the retriever. Then the name clashes when we try to make a directory with the same name? We shouldn't allow for retrievers to return files in the example path as many bad things will happen. IMO we should raise an error instead and fix the tests.