Pathlib object handling for Universe, SingleFrameReaderBase and Toplogy parsers (Issue #3937)

[talagayev]

Partially Fixes #3937. The issue mentioned the addition of support and testing for pathlib objects for SingleFrameReaderBase.

Currently the SingleFrameReaderBase is able to handle both pathlib and str as input for SingleFrameReaderBase to display this, this PR is focusing on tests that display the handling of pathlib and str as input for SingleFrameReaderBase .

Changes made in this Pull Request:

• Addition of tests for pathlib object and str input for SingleFrameReaderBase in test_gro.py and test_lammps.py

Currently the tests are as mentioned for GRO and LAMMPS cases. SingleFrameReaderBase also recognizes INPCRD, CRD, NAMDBIN and DMS if given as a single input, so tests for these cases could also be added if required.

PR Checklist

• Tests?
• Docs?
• CHANGELOG updated?
• Issue raised/referenced?

Developers certificate of origin

• I certify that this contribution is covered by the LGPLv2.1+ license as defined in our LICENSE and adheres to the Developer Certificate of Origin.

---

📚 Documentation preview 📚: https://mdanalysis--4535.org.readthedocs.build/en/4535/

[pep8speaks]

Hello @talagayev! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file package/MDAnalysis/topology/base.py:

Line 119:1: W293 blank line contains whitespace

• In the file testsuite/MDAnalysisTests/coordinates/base.py:

Line 548:1: W293 blank line contains whitespace
Line 549:47: W291 trailing whitespace
Line 553:80: E501 line too long (86 > 79 characters)

Comment last updated at 2024-12-17 20:40:44 UTC

[github-actions]

Linter Bot Results:

Hi @talagayev! Thanks for making this PR. We linted your code and found the following:

Some issues were found with the formatting of your code.

Code Location	Outcome
main package	⚠️ Possible failure
testsuite	⚠️ Possible failure

Please have a look at the darker-main-code and darker-test-code steps here for more details: https://github.com/MDAnalysis/mdanalysis/actions/runs/10542931892/job/29210309319

---

Please note: The black linter is purely informational, you can safely ignore these outcomes if there are no flake8 failures!

[codecov]

Codecov Report

❌ Patch coverage is 89.47368% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.72%. Comparing base (3189d48) to head (54cbf7a).

Files with missing lines	Patch %	Lines
package/MDAnalysis/coordinates/base.py	80.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #4535   +/-   ##
========================================
  Coverage    92.72%   92.72%           
========================================
  Files          180      180           
  Lines        22458    22473   +15     
  Branches      3186     3192    +6     
========================================
+ Hits         20824    20838   +14     
  Misses        1177     1177           
- Partials       457      458    +1     

☔ 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.

[orbeckst]

@hmacdope would you be able to look at this PR or assign to someone else, please?

[hmacdope]

Apologies for the delay @orbeckst @talagayev, was away over easter. Reviewing now.

[hmacdope]

@talagayev you have the right idea of what to test, and your test implementations are good!

However to achieve better coverage and to make your tests more powerful you can instead add your tests to BaseReaderTest and _SingleFrameReader that cover the base API functionality for all relevant trajectory types. This is in estsuite/MDAnalysisTests/coordinates/base.py. :)

[talagayev]

@hmacdope

@talagayev you have the right idea of what to test, and your test implementations are good!

However to achieve better coverage and to make your tests more powerful you can instead add your tests to BaseReaderTest and _SingleFrameReader that cover the base API functionality for all relevant trajectory types. This is in estsuite/MDAnalysisTests/coordinates/base.py. :)

Ah, I think i see :) i would than adjust it so that the tests are in BaseReaderTest and _SingleFrameReader.

Does it than make also sense to move the ReaderBase tests from #3935 also in the same way in a separate PR? since currently from the tests they cover two cases, one in the testsuite/MDAnalysisTests/coordinates/test_dcd.py for PSF&DCD and testsuite/MDAnalysisTests/coordinates/test_xdr.py for GRO&XTC ?

[talagayev]

@hmacdope
I managed to get the test locally in _SingleFrameReader and it covers the cases, but trying to add it into BaseReaderTest leads to errors such as:

AttributeError: 'PosixPath' object has no attribute 'encode'

in the case of test_dcd.py. Here it has problems with the TestDCDReader with also having the same errors with the TRRReader and XTCReader , whereas it is fine in test_gro.py with the TestGROReader. Is it possible that TestDCDReader also does access BaseReaderTest, which leads to the error, since it possibly needs a different case of handling than TestGROReader. Does it make sense to leave the test for the SingleFrameReaderBase in _SingleFrameReader and make one for MultiframeReaderTest so that both cases are divided and tested separatly in their classes?

[talagayev]

@hmacdope
Hey Hugo, I adjusted now the tests and moved them to base.py as you suggested. As I mentioned there were the problems with the cases when i applied the tests for the single frame pathway to formats such as DCD, XTC so the ones that are not SingleFrameReader formats and thus I had to set exceptions for these cases.
Could you take a look if everything is fine now? For the checks most of them failed on the codecov stage in the end, so i am not sure if it is an error from the codecov site. Thanks in advance :)

[hmacdope]

@talagayev sorry for the delay here. I will review ASAP.

[talagayev]

@hmacdope all good, no worries :)

[orbeckst]

@hmacdope would it be worthwhile reviewing again? Can this PR be pushed across the finish line?