Open barronh opened 7 months ago
I suspect that all the instantiation options[1] should be passed thru to the Operator
instantiation. I can't imagine setting a bunch of the options and then having them lost on all the operators.
[1] https://github.com/Try2Code/cdo-bindings/blob/master/python/cdo/cdo.py#L152-L163
When cdo is not on the users path or when the cdo to be used is different, the version 1.6.0 will not work. This was not a problem with v1.5.x. To reproduce the error, look at the example failure section. The fix is surprisingly simple and is described in the resolution section.
Should I fork and make a PR?
Resolution
I think I have traced it down to differences between the
Operator
class.[1,2] In the new code, the init explicitly uses *args and **kwds, which are not provided. As a result, thecdo
argument is lost to the child operators. This can be resolved by explicitly passing the CDO proprity as the argument to Operator.[1] https://github.com/Try2Code/cdo-bindings/blob/master/python/cdo/cdo.py#L570-L581 [2] https://github.com/Try2Code/cdo-bindings/blob/maintenance-1.5.x/python/cdo.py#L608-L614
Example Failure
For example, I have a cdo binary at /usr/local/apps/cdo-2.2.1/intel-21.4/bin/cdo, which is not in my path.
But it is fully functional
If I use the python bindings with a specified, I get an error
FileNotFoundError: [Errno 2] No such file or directory: 'cdo'
Error:
Using pdb, I can go up to 580 line where self.CDO is as expected and calling
Operator()
raises the error.