Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds jupyter-run to jupyter_client #184

Merged
merged 11 commits into from
Feb 7, 2017
Merged

Adds jupyter-run to jupyter_client #184

merged 11 commits into from
Feb 7, 2017

Conversation

dsblank
Copy link
Member

@dsblank dsblank commented Aug 9, 2016

No description provided.

stream = getattr(sys, content['name'])
stream.write(content['text'])
elif msg_type in ('display_data', 'execute_result', 'error'):
if msg_type == 'error':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This nesting is a bit odd - why not have elif msg_type == 'error' broken out separately before display_data and execute_result.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is cut and paste from Min's link:

https://github.com/dask/distributed/pull/370/files#diff-b7f744240c50427e50e9c844a13a00fdR43

so @minrk can comment on that.

@takluyver
Copy link
Member

If I do jupyter run foo.py, and it errors, I certainly think the process should exit with code 1, so that e.g. CI knows something has gone wrong.

If I do jupyter run foo.py bar.py and there's an error running foo.py, IMO it should stop without running bar.py.

@dsblank
Copy link
Member Author

dsblank commented Aug 9, 2016

Agreed regarding stopping-on-error. I added two checks for error conditions, as I found some kernels had not yet used the error message type, so printing on stderr is also detected as an error code here.

@dsblank
Copy link
Member Author

dsblank commented Aug 9, 2016

Mentioning #183 as I forgot before. This should take care of that issue.

@takluyver
Copy link
Member

Sorry, I don't think printing to stderr should count as an error - it's common to write logging and things to stderr even when there's no exception condition.

We should, however, get the execute_reply message from the shell channel and check for 'status': 'error' or 'status': 'aborted' on that.

@dsblank
Copy link
Member Author

dsblank commented Aug 9, 2016

@takluyver I agree about counting as an error. However, there some kernels that need to be update to be able to handle this. I'll add "aborted" too.

return_code = 1
else:
sys.stdout.write(content['data'].get('text/plain', ''))
elif msg_type == 'aborted':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a message type. We need to get a message from the shell channel with self.kernel_client.get_shell_msg, check that it's an execute_reply message, and check its 'status' field.

http://jupyter-client.readthedocs.io/en/latest/messaging.html#execution-results

@minrk
Copy link
Member

minrk commented Aug 9, 2016

Exit code should only consider the status field of the execute_reply. Outputs shouldn't be relevant.

@dsblank
Copy link
Member Author

dsblank commented Aug 10, 2016

Removed the break condition when printing to stderr, and removed the "aborted" msg_type handler. Somehow, this needs to poll handle iopub and shell, and print output from both. But I don't think @minrk 's dask link was doing this, right?

@dsblank
Copy link
Member Author

dsblank commented Aug 10, 2016

Oh, I think I see my issue: not all kernels publish the execute_reply also on the iopub channel. If they do, I think that this will work. What would probably also make this more clear is:

  • documenting what is done with the error message parts (evalue, and ename; that traceback is a list of lines ending with a newline, etc)
  • simple_kernel should show how to handle errors

@takluyver
Copy link
Member

No kernels should publish execute_reply on the iopub channel.

When the kernel gets an execute_request message on the shell channel, it sends 0 to N output messages on iopub, which may include messages with msg_type error (in addition to stream, display_data, execute_result). Then it sends precisely one execute_reply message on the shell channel, which indicates that the requested execution is done, and includes a status field (ok/error/aborted).

So the error information can be duplicated: in an error message on iopub, and the execute_reply message on shell. This is certainly somewhat confusing, and we hope to simplify it in a future version of the message spec, but that's what we have for now.

There should be no need to poll shell or print output from it. We can poll iopub until we get the status:idle message telling us that we've seen all outputs. And then we can fetch the execute_reply message from shell.

@dsblank
Copy link
Member Author

dsblank commented Aug 11, 2016

@takluyver Ok, thanks. That is confusing, and isn't reflected in the code that @minrk linked to, that I can see. I don't see how the code would keep the error message from printing out twice, if it can come in two forms (one on iopub and one on shell).

I think I'll wait for someone to write the ultimate function for handling this. Then I'll call it from this code.

@minrk
Copy link
Member

minrk commented Aug 11, 2016

@dsblank thanks! I opened #185 adding BlockingKernelClient.run, which should be the implementation of the messaging. After that gets in, you should be able to simplify this one with:

reply = self.kernel_client.execute(code, reply=True)
exit_code = 0 if reply['content']['status'] == 'ok' else 1

@dsblank
Copy link
Member Author

dsblank commented Aug 11, 2016

Updated PR to use reply=True. Very nice!

@dsblank
Copy link
Member Author

dsblank commented Aug 12, 2016

I think that this can be tagged 4.5 like #185

@takluyver takluyver added this to the 4.5 milestone Aug 12, 2016
@rgbkrk
Copy link
Member

rgbkrk commented Sep 7, 2016

Neat.

@minrk minrk modified the milestones: 5.0, 4.5 Feb 7, 2017
@minrk minrk merged commit b209e1b into jupyter:master Feb 7, 2017
@minrk
Copy link
Member

minrk commented Feb 7, 2017

@dsblank sorry for the delay on this one. Thanks!

Marked as 5.0, since that's what the next release will be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants