<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>I'm starting to think about how newly installed kernels can be discovered by IPython, and the links between kernels and profiles.<br><br></div>At the moment, the way to use a non-default kernel (such as IJulia) is to specify its arguments in a config value. As a shortcut, you can create a profile with this setting, and then launch IPython using that profile (e.g. --profile=julia). However, we'd like to make it possible to start different kernels from one notebook server (and presumably from one Qt console). When a kernel is installed, there should be a simple way for it to tell IPython of its existence, and how to start it.<br>

<br></div>A profile is a collection of settings, along with its own command history. There may well be more than one profile for a given kernel - e.g. we ship a few Python profiles that load different libraries on startup. In some cases, it may also make sense to have more than one kernel per profile: the default profile is currently used for both Python 3 and Python 2. In most cases, however, it probably makes sense for each profile to be associated with one kernel.<br>

<br></div>So, I propose:<br></div>- On installation, kernels should place a small json file in a specific directory. There will be a per-user directory (e.g. ~/.ipython/kernels) and a systemwide one (e.g. /usr/share/ipython/kernels)<br>

</div>- IPython will offer a mechanism to open a notebook (or run kernels by other means) with a specific profile<br></div>- The list of 'profiles' will include the names of kernels that don't yet have a matching profile. When one of these is selected, a matching profile will be created - so the first time you use the Haskell kernel, say, a profile_haskell profile folder is made.<br>

</div>- The profiles can specify a kernel definition file, instead of including kernel details directly in config. This allows the kernel definition to be updated later, if e.g. command line arguments change.<br><br></div>

Does this sound sensible?<br><br></div>Then there's the question of how to handle multiple kernels sharing a profile. We could allow a general mechanism for this, or special case the Python 2/3 kernels, or just drop the possibility and force the Python kernels to use separate profiles.<br>

<br></div>Thanks,<br>Thomas<br></div>