-
Notifications
You must be signed in to change notification settings - Fork 667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed lockfile check when using a Docker read-only filesystem #3832
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello there first time contributor! Welcome to the MDAnalysis community! We ask that all contributors abide by our Code of Conduct and that first time contributors introduce themselves on the developer mailing list so we can get to know you. You can learn more about participating here. Please also add yourself to package/AUTHORS
as part of this PR.
Codecov ReportBase: 94.32% // Head: 94.31% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #3832 +/- ##
===========================================
- Coverage 94.32% 94.31% -0.01%
===========================================
Files 194 194
Lines 25062 25064 +2
Branches 3390 3391 +1
===========================================
+ Hits 23639 23640 +1
- Misses 1374 1375 +1
Partials 49 49
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Thanks @jfennick - since there are no related issues and it'll be hard to test the error, could you explain in more details what was the cause for this fix / any code/docker env details to duplicate the issue? |
Sure. Here is the relevant command line + stack trace from my log file.
For purposes of reproducibility/distribution with Common Workflow Language scripts, I am embedding align_protein_CA_mda.py within my Docker image jakefennick/scripts. My script works fine outside of Docker, but a Docker image is of course a read-only filesystem which causes MDAnalysis to raise an OSError, not a PermissionError. For testing purposes, align_protein_CA_mda.py is rather trivial and should work with any standard gro and trr files. |
I guess I should clarify that |
@@ -197,7 +197,7 @@ def _load_offsets(self): | |||
try: | |||
with fasteners.InterProcessLock(lock_name) as filelock: | |||
pass | |||
except PermissionError: | |||
except (PermissionError, OSError): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A reproducer for the original handled PermissionError is straightforward, like below, I wonder if we could cook something up for the other error? May not be worth much energy though.
--- a/testsuite/MDAnalysisTests/coordinates/test_xdr.py
+++ b/testsuite/MDAnalysisTests/coordinates/test_xdr.py
@@ -904,3 +904,14 @@ class TestTRRReader_offsets(_GromacsReader_offsets):
9155712, 10300176
])
_reader = mda.coordinates.TRR.TRRReader
+
+
+def test_offset_readonly_handle(tmpdir):
+ with tmpdir.as_cwd():
+ curr_path = os.getcwd()
+ new_gro = os.path.join(curr_path, os.path.basename(GRO))
+ new_xtc = os.path.join(curr_path, os.path.basename(XTC))
+ shutil.copyfile(GRO, new_gro)
+ shutil.copyfile(XTC, new_xtc)
+ os.chmod(curr_path, 0o555)
+ u = mda.Universe(new_gro, new_xtc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking for OSError
only seems too broad to me (for details see my code comment).
@@ -197,7 +197,7 @@ def _load_offsets(self): | |||
try: | |||
with fasteners.InterProcessLock(lock_name) as filelock: | |||
pass | |||
except PermissionError: | |||
except (PermissionError, OSError): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the Python docs, PermissionError
is a subclass of OSError
, so your code is currently equivalent to only checking for OSError
.
I'd advise against a simple check for OSError
only, though, as this exception class covers many kinds of OS-related errors.
To narrow down the cause of the exception, it might be better to catch OSError
, then check if it's a PermissionError
or the errno
member of the exception is the one you encountered. If so, raise the warning as before, otherwise just raise
for the exception to bubble up.
For checking the errno, there should be a suitable constant in the errno
module of the standard library so you don't have to hard-code numbers here.
EDIT: It's errno.EROFS
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, just a few nitpicks. If you re-raise an exception, make sure to only use a bare raise
statement without arguments. If you use raise e
, the original exception trace won't be preserved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. @tylerjereddy already commented on testing this so I'll approve once he's ok with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to put a short hold on new contributions for a few days re: licensing (sorry about this) - I'll release a blog post explaining why tonight / tomorrow hopefully, nothing big just need to work out what's our plan before we continue
Any movement on this issue? |
Sorry about this @jfennick - I didn't get much headway on the alluded to blog post (fingers crossed end of this week). I'm dismissing my block, but could I ask you that you introduce yourself on the mailing list as per #3832 (review) before we merge this? We will need to trace contributors in the near future, so we need a way to reach out to everyone. |
Is there anything else I need to do to get this merged? If licensing issues are impeding drive-by contributions, then in the future perhaps I'll simply submit Issues instead of PRs. |
@zemanj you have a blocking review here, could you have another look please? |
Sorry about the long time to merge, the licensing stuff is not a blocker here (I dismissed my review some time back alongside #3832 (comment)). I'll give @zemanj until next week to re-review otherwise I'll take over and approve. |
@IAlibay just scrolling through and thought I would give this a bump. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm sorry this took so long @jfennick I'm not familiar with this part of the code so I didn't want to dismiss things rapidly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I completely forgot - could you add yourself to AUTHORS
@jfennick ?
Sorry about the last two commits, just thought it was faster for me to just add you to the changelog and fix the merge conflicts in one. |
No problem. Whatever works. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
CI failure is being solved in #3886 I'm going to go ahead with the squash merge to not hold things up. |
Fixes #
Changes made in this Pull Request:
PR Checklist