Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Pass config to kernel from ExecutePreprocessor for configurable kernels #816
This became a much larger PR due to my efforts to write tests for the original PR.
Most notably, this does the refactor that I proposed in @MSeal's #811 to make it easier to overwrite the
It creates 2 new public methods, and adds a dynamic default to an existing traitlet:
This also changes the value of the default
Smaller original PR:
Pass config to kernel from ExecutePreprocessor for configurable kernels
Right now, the way that we're instantiating the kernels means any configuration that can be passed to those kernels stops at the point where we actually create the Kernel.
If you want any custom Kernels to be configurable (e.g., to use a different
I still need to add tests to make sure that configuration is passed through more directly. This is partially why I wanted the
referenced this pull request
May 19, 2018
This looks sensible for now, but if we do adopt my WIP new kernel machinery (see #809), the ability to pick a kernel manager class will go away, because the kernel manager is something that the kernel provider gets to decide. I.e. you ask it to start a kernel of type
The good news is that there should be less reason for the frontend to set the kernel manager class, because it affects less. In particular, it sounds like you want to configure it to affect finding and starting a kernel, which is all moved out of kernel manager in the new machinery.
For passing parent/config: it looks like there's some long forgotten magic in traitlets so if we use
I'm fine with that, I just want to make sure that the motivation for adding this configurability is not something that we're going to irrevocably break if/when we do adopt the new machinery. If the motivation is to replace