BUG: ResourceWarnings for unclosed files in boxlib frontend

[yut23]

Bug report

Bug summary

open() is used several times in the boxlib frontend without closing the files, triggering a ResourceWarning when the files go out of scope. Originally noticed by @neutrinoceros in https://github.com/yt-project/yt/issues/4845#issuecomment-2029735171.

Code for reproduction

Standalone reproducer using the ParticleCavity dataset:

import warnings
import yt

# enable all warnings
warnings.simplefilter("default")
ds = yt.load("plt.Cavity00010")

Actual outcome

/home/eric/build/yt/yt/frontends/boxlib/data_structures.py:701: ResourceWarning: unclosed file <_io.TextIOWrapper name='/scratch/yt-data/plt.Cavity00010/inputs' mode='r' encoding='UTF-8'>
  lines = [line.lower() for line in open(cparam_filepath).readlines()]
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/home/eric/build/yt/yt/frontends/boxlib/data_structures.py:728: ResourceWarning: unclosed file <_io.TextIOWrapper name='/scratch/yt-data/plt.Cavity00010/Header' mode='r' encoding='UTF-8'>
  self._parse_header_file()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
yt : [INFO     ] 2024-04-30 14:59:50,921 Parameters: current_time              = 0.017408426036316
yt : [INFO     ] 2024-04-30 14:59:50,921 Parameters: domain_dimensions         = [16 16  1]
yt : [INFO     ] 2024-04-30 14:59:50,921 Parameters: domain_left_edge          = [0. 0. 0.]
yt : [INFO     ] 2024-04-30 14:59:50,922 Parameters: domain_right_edge         = [1. 1. 1.]

Expected outcome

No warnings.

Version Information

• yt version: 4.4.dev0, cd4f1d69cd3f (current git head)

[yut23]

I misunderstood the problem that @neutrinoceros raised in his comment. As noted in conftest.py, we explicitly ignore this class of warnings during tests, and they're ignored by default during normal usage. I'm leaving the PR open, as closing the files is probably a good idea anyways.

[neutrinoceros]

Interesting. I didn't mean to suggest that the problem existed on main, but maybe it does, and in that case it cannot be a blocker to #4845. Your PR clearly shows that's indeed the current state so I suggest we keep this open too.