Fix test to check if we are printing --allow-partial when a user uses --allow-partial

[mikemhenry]

Checklist

• Added a news entry

Developers certificate of origin

• I certify that this contribution is covered by the MIT License here and the Developer Certificate of Origin at https://developercertificate.org/.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.21%. Comparing base (6581c95) to head (8be0fc0).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1564      +/-   ##
==========================================
- Coverage   95.25%   93.21%   -2.05%     
==========================================
  Files         172      172              
  Lines       14492    14492              
==========================================
- Hits        13805    13508     -297     
- Misses        687      984     +297     

Flag	Coverage Δ
fast-tests	93.21% <100.00%> (?)
slow-tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mikemhenry]

@atravitz I am a bit confused by this regex, what are we to do with this test? I feel like # we *dont* want the suggestion to use --allow-partial if the user already used it! implies we are trying to make sure that if a user has --allow-partial we DON'T want it to warn us that they can use that option. But I think the regex is the same as match='[^using the\-alowpr]' (the test still passes if I use that match string) Which is like "match if there is a warning that doesn't have any of these chars"

So then when we get a warning like ResourceWarning("unclosed file <_io.TextIOWrapper name='/home/mmh/.cache/openfe/rbfe_results_serial_repeats.tar.gz.untar/rbfe_results_serial_repeats/rbfe_lig_ejm_46_solvent_lig_jmc_28_solvent/shared_RelativeHybridTopologyProtocolUnit-60df96a488094f63978880d19487d299_attempt_1/db.json' mode='r' encoding='UTF-8'>") since it has some chars that don't match, the regex matches so then the test passes.

I don't think pytest.warns works for warnings that don't come from python API and I think we are using it here to check for warnings that we expect to be printed to std out/err, so what we need to do is loop though what the command returns and check to make sure we don't see that string in the output.

At least that is what I took away from a quick look at this, I could be totally wrong!

[atravitz]

thanks for catching this! was this causing an error, or did you find it another way?

[mikemhenry]

I saw the warning about the escape syntax when I was working on an unrelated thing and you know how I like a good investigation on an esoteric code path!

This fixes the escape warning, but what are we trying to test with this test?

[atravitz]

@mikemhenry is this comment unclear? I added this test because when we ran with --allow-partial, it was still adding the you can use --allow-partial to stdout, which I think is confusing.

[atravitz]

I missed your earlier comment before, and now I understand why this test is insufficient. Is your suggestion that we assert that you can use --allow-partial is not in stdout?

[github-actions]

No API break detected ✅

[atravitz]

thank you, LGTM!