Gracefully fallback to subprocess when Python wrappers not available/insufficient

Question

Gracefully fallback to subprocess when Python wrappers not available/insufficient

Closed this issue 5 years ago · 14 comments

This should at least fix the Windows build so that we're not going backwards.

Answer 1 · 2019-07-06T21:25:46.000Z

We should also fallback if we don't support the specified flags/combination of them.

Answer 2 · 2019-07-12T06:46:41.000Z

@Vaydheesh why is the Windows build still not working? You mentioned something about lrx-proc but I didn't really catch it.

Answer 3 · 2019-07-12T07:26:06.000Z

https://ci.appveyor.com/project/sushain97/apertium-python/builds/25755769/job/sx0oreu75t67vq9l#L210
lrx-proc -m seems to be expecting input from stdin on windows. I tried building lrx-proc on windows itself, and the last working commit was apertium/apertium-lex-tools@4165215

Should I log messages when calling processes upon falling back to subprcoess implementation?
This would help in finding the exact cause in future.

Answer 4 · 2019-07-12T07:34:35.000Z

https://ci.appveyor.com/project/sushain97/apertium-python/builds/25755769/job/sx0oreu75t67vq9l#L210
lrx-proc -m seems to be expecting input from stdin on windows.

Ah. This was working before, right?

I tried building lrx-proc on windows itself, and the last working commit was apertium/apertium-lex-tools@4165215

As in, it doesn't build after this commit or it hangs only after this commit?

Should I log messages when calling processes upon falling back to subprcoess implementation?

I'm not sure what you would log but go ahead and try? You can also run it locally, yes? If not: https://www.appveyor.com/docs/how-to/rdp-to-build-worker/.

Answer 5 · 2019-07-12T07:39:16.000Z

lrx-proc was working till apertium/apertium-lex-tools@4165215
It failed on apertium/apertium-lex-tools@2a77a50

I'm not sure what you would log but go ahead and try?

I want to log the calling of each subprocess if python wrappers aren't available, like https://ci.appveyor.com/project/sushain97/apertium-python/builds/25755769/job/sx0oreu75t67vq9l#L210, RN its only showing test_en_spa (tests.TestTranslate) ... https://ci.appveyor.com/project/sushain97/apertium-python/branch/master/job/9of59fyjciehgltr#L195
This might come handy if something fails during future builds

Answer 6 · 2019-07-12T19:12:25.000Z

Sure, feel free to log at debug level. Can you talk to @unhammer about what might be wrong now? It seems like an error unrelated to swig entirely (you can confirm this on Windows?).

Answer 7 · 2019-07-12T19:18:26.000Z

I'll re-compile this(just to be sure) and then discuss this tomorrow

Answer 8 · 2019-07-13T10:36:57.000Z

Can we remove -m flag, when calling lrx-proc during subprocess implementation. This should pass the test case in appveyor, until a fix is pushed on apertium-lex-tools

Answer 9 · 2019-07-13T17:17:28.000Z

Uhh, I'm opposed to arbitrarily removing flags with semantic value. Presumably removing the -m flag will change how a pair actually behaves and therefore is not OK.

Answer 10 · 2019-07-14T06:05:58.000Z

There were discussions on actually removing the mode without -m, so default acted the same way. We probably should wrap up that conversation

Answer 11 · 2019-07-14T17:46:59.000Z

@xavivars makes sense. That being said, we can't just willy nilly remove the -m from the mode pipe, yes?

Answer 12 · 2019-08-01T05:10:08.000Z

@sushain97 Should I close this issue if any changes aren't required

Answer 13 · 2019-08-01T05:10:37.000Z

Is there another issue tracking adding tests for this? If so, go ahead and close this one, yes.

Answer 14 · 2019-08-01T05:12:51.000Z

The subprocess tests are tracked here #54