This is one way to fix the recent mailing list report.
$ rm -fr ~/.ipython/profile_sympy/
$ ipython notebook --profile=sympy
[NotebookApp] Profile u'sympy' not found.
$ ipython --profile=sympy
works fine, and ipython notebook --profile=sympy will work thereafter. In this PR, I added set the auto_create flag for notebook apps to True, which makes the top code block work just fine.
ipython notebook --profile=sympy
An alternative would be to make auto_create = True for the base application. I'm not sure which one should be done, but would be happy to change this pull request to the alternative, which would look like this:
auto_create = True
diff --git a/IPython/core/application.py b/IPython/core/application.py
index 4b49a94..cf099bb 100644
@@ -124,7 +124,7 @@ class BaseIPythonApplication(Application):
overwrite = Bool(False, config=True,
help="""Whether to overwrite existing config files when copying""")
- auto_create = Bool(False, config=True,
+ auto_create = Bool(True, config=True,
help="""Whether to create profile dir if it doesn't exist""")
set auto_create flag for notebook apps
Nice - the reason it's not on by default is that some apps should only load config, so if you specify a profile that doesn't exist it should raise (e.g. ipengine). That said, those that should not create profiles seem to be the minority, so switching the default may make sense. That would mean adding auto_create=Bool(False) override to any apps that do not currently have the auto_create=Bool(True) override now.
right, in that case, maybe it makes sense to leave the default, for the benefit of other folks that are depending on the current default.
Makes sense. It is also the more conservative value, and the right choice for potential new apps that do less. In that case, setting profile to one of those that is bundled should probably imply auto_create=True.
sorry if I'm confused - but I was talking about leaving the default for BaseIPythonApplication, and changing it for NotebookApp, as per this PR. I realized as I reread your comment that mine could have been read as "leaving the default for the NotebookApp as auto_create=False" - but that's not what I meant.
I would side with making the BaseIPythonApplication default True, because if people build other frontends using that class, they'll expect them to behave in the same way as regular IPython applications.
@ivanov - I understood what you meant, but even so, I don't think the profile doesn't exist error shouldn't raise if you request a bundled profile for the first time, even for an app where auto_create=False. But auto_create should certainly be True in the NotebookApp as you have done. This need not be addressed in this PR, as I suppose it's a separate issue.
profile doesn't exist
@takluyver - That would also be addressed by making ShellApp set auto_create=True, and the NotebookApp should be a subclass of ShellApp, just like everything else that starts IPython shells, and this is what third-party apps should inherit from anyway. It was a mistake to write it as we did, by copying/pasting a bunch of code, which has allowed it to fall out of sync as the original code was updated an improved.
The case for leaving the default as False is that apps for which False is the right default are ones that do less.
Originally, profiles had to be created with ipython profile create, but we realized that when you start an IPython shell, you should be able to simply ask for a profile, and it will be created without staging any config files (or only those that are bundled). This is not the case in general, and in particular is not the case for things that must load some config (ipengine, iplogger, ipcluster subcommands other than start), where no pre-existing config does mean there's definitely an error. Since it has turned out that these are a minority of entry points, it may make sense to switch the default to True, which would require adding overrides to all apps that currently inherit the default, just as shell-starting apps and ipcontroller have overrides in the opposite direction now.
ipython profile create
Since this code actually fixes an important bug and is perfectly consistent with the rest of the existing logic, I'm going to merge it, and we can decide what to do about rearranging the default auto_create in another Issue.