JEP for specifying the connectionfile #106
Conversation
|
@jupyter/software-steering-council kind ping on this one, similar to #105 |
|
I propose we move this to a voting phase. This has been open for nearly a year, so I think we can safely close the comment period. Now that the jupyter/schema repo is moving forward, this seems like a good time to proceed. |
| "description": "ip of the machine where the kernel runs" | ||
| }, | ||
| "shell_port": { | ||
| "type": ["integer","string"], |
There was a problem hiding this comment.
Is it worth using oneOf to distinguish tcp with integer ports from ipc/inproc where it's really a string suffix (that I believe implementation-wise accepts integers)? Essentially, signal that tcp doesn't accept strings for ports.
Fine if that's more schema complexity that folks want.
| }, | ||
| "kernel_network": { | ||
| "type": "object", | ||
| "required": ["transport", "ip", "shell_port", "control_port", "stdin_port", "hb_port", "iopub_port"], |
There was a problem hiding this comment.
I realize I'm late to this discussion, but I just want to understand it fully before voting: Is the spec as proposed now consistent with https://github.com/jupyter/enhancement-proposals/pull/66/files ? If not, how would the schema evolve to support that? Would these fields no longer be required?
There was a problem hiding this comment.
Ok. My main point was to do a sanity check on whether #66 would require any changes that the spec as it currently is would make harder to implement. It sounds like that isn't a concern, so I voted for.
|
The JEP has been approved unanimously.
Merging |
Connection file JSON schema
This proposes to specify the connection file through a JSON schema, and have the specification and documentation live in a dedicated repo.
The JSON schema is joined as a standalone file.
I(s been a while since we proposed to move to the voting phase, let's fix it now ;) Ntice that further JSON specs should not been JEPs, but PRs to https://github.com/jupyter/schema
Voting from @jupyter/software-steering-council