Open minrk opened 9 years ago
No objections from me.
Missed the boat for 4.0 on this one, but I still think it's the right move in the long run.
FYI, we use the ipyparallel bits in wrapper kernels (via metakernel) to run other languages in parallel. This is quite powerful, and hope that we can keep that functionality.
@dsblank how do you use those kernels in parallel? Are you using ipyparallel at all? I mainly mean to remove the native-serialization stuff (data-pub, apply), not anything else, which shouldn't affect any kernels other than IPython.
@dsblank I've implemented most of what I intended in ipython/ipyparallel#61. I don't understand enough about how your use of parallel in metakernel works, so I don't know how to tell what would be affected. Can you provide some examples that I can test with?
Sorry for the delay. Here is a short example:
pip3 install metakernel_bash --user
%parallel metakernel_bash MetaKernelBash
%px uname
Hopefully that will still work. Thanks!
@dsblank thanks, that still works after the above PR. Since it looks like you are sitting on top of the existing IPython engines and clients, moving the implementation shouldn't have any effect on your use case.
Thanks for checking @minrk ! It is quite nice to have Parallel Java, Parallel Scheme, Parallel Cobol ...
bump to 6.0 ?
Mainly the
apply
message-related bits. These aren't part of the wider Jupyter message protocol, and are wholly Python specific. These can be moved to ipyparallel, and attached to the Kernel in a subclass.