Open dermen opened 4 years ago
@dermen could you work around this by monkeypatching[1]? i.e. in your application code replace the definition of fully_buffered_base.raise_if_errors()
with one which is a logical no-op returning self?
Python is great as it allows that kind of activity... we did that in DIALS for a long while to get around the "feature" of exploding if any library code had a NaN in a conditional which was never touched.
Well in this case its not my application, rather a software supported command line script, cspad.cbf_metrology
, so all I have freedom to do is change the command line arguments :)
I am not sure how prevalent the
raise_if_errors
is in the code base, but it recently got me on a harmless versioning error akin to this.I was trying to run
cspad.cbf_metrology
but it continually failed due to theraise_if_errors
catching the version error, however when I removed all of theraise_if_errors()
calls the program proceeded successfully.I will add that in my case the versioning error is to do with libreadline but it never results in anything other than the minor annoyance of seeing the error message pop up.
Is this something that should / could be addressed ? I find it difficult sometimes to maintain a perfect build free of any minor-versioning hiccups, especially on servers where I am not free to choose the operating system (e.g. the NERSC server Im on now runs openSUSE Leap 15.0)