Kivy app import effects Rpc

[timeyyy]

Background

neovim is a hackers vim with a nice community. They have seperated the ui and gui and expose the communication via rpc. I want to make a kivy interface for vim so i can have a vim text editor widget for kivy.

The Bug

The following code runs fine if we comment the line with kivy in it

from kivy.app import App # commenting this lets us spin up a neovim proceess and communicate with it
from distutils.spawn import find_executable
from neovim import attach

nvim_binary = find_executable('nvim')
args = [nvim_binary, '--embed']
nvim = attach('child', argv=args) # this call doesn't work properly with our kivy import..

With the import kivy line, the last line blocks. It's trying to do an rpc call.

[Zen-CODE]

Personally, I don't think this could really be called a bug yet. Kivy is self contained and cannot provide support for external tools that do their own thing. Not that we don't want to get it working, just that we cannot provide support for every library. The code above in no way demonstrates kivy is doing anything wrong.

I would suggest posting on the forums and seeing if anyone can give you insight there, although without an error log, there is not much to go on...

@timeyyy
Please close if you agree, or comment otherwise.

[timeyyy]

All i'm saying is something weird is going on... I will keep digging into this, i will also be working with the neovim devs. Can i leave this open as a place to post further updates and get feedback?

I can also close this and post in the forum if that is more common practice here.

[Zen-CODE]

Sure. You can still post here on your findings and then re-open it if you find it is a flaw in kivy...

Thanks for taking the time. I hope it works out 👍

[Zen-CODE]

Oh, can I suggest trying the call on a Clock.schedule_once? Or running it on a separate thread?

[timeyyy]

That snippet i posted above is the whole file. Literally that one line import stops me being able to connect over rpc to neovim. I posted a traceback on the neovim issue above,

i think it could be that attching in child mode is using stdio which kivy is using somehow? I will try one of the other transport types

[timeyyy]

The behavior only happens when i am using the child method to connect

   _connect_child(argv): Use the argument vector `argv` to spawn an
          embedded Nvim that has it's stdin/stdout connected to the event loop.

i'm guessing it is because kivy is doing stuff with stdin/stdout

[bfredl]

No, attach('child') does not use the python stdio handles, from python point of view it is a newly created pair of pipes. You mean you can still connect to a existing nvim instance over a named pipe ( attach('socket', path=...) ) ?

[timeyyy]

i used attach('headless')
It worked, meaning that the call didn't block, like it is doing above (didn't actually test it further)

also attach('socket', ..) "works"

[Zen-CODE]

Great. Thanks both for the follow ups...

[timeyyy]

for closure:

it appears neovim abuses sys.stderr.fileno() to get the stderr file number, which might not work because Kivy takes over sys.stderr.