Show More
@@ -46,7 +46,7 b' There are two ways you can tell IPython to use your extension:' | |||
|
46 | 46 | To load an extension called :file:`myextension.py` add the following logic |
|
47 | 47 | to your configuration file:: |
|
48 | 48 | |
|
49 |
c. |
|
|
49 | c.InteractiveShellApp.extensions = [ | |
|
50 | 50 | 'myextension' |
|
51 | 51 | ] |
|
52 | 52 |
@@ -15,63 +15,74 b' can configure the application. A sample is provided in' | |||
|
15 | 15 | :mod:`IPython.config.default.ipython_config`. Simply copy this file to your |
|
16 | 16 | :ref:`IPython directory <ipython_dir>` to start using it. |
|
17 | 17 | |
|
18 | Most configuration attributes that this file accepts are associated with | |
|
19 |
|
|
|
18 | Most configuration attributes that this file accepts are associated with classes | |
|
19 | that are subclasses of :class:`~IPython.config.configurable.Configurable`. | |
|
20 | 20 | |
|
21 | A few configuration attributes are not associated with a particular | |
|
22 | :class:`~IPython.core.component.Component` subclass. These are application | |
|
23 | wide configuration attributes and are stored in the ``Global`` | |
|
24 | sub-configuration section. We begin with a description of these | |
|
25 | attributes. | |
|
21 | Applications themselves are Configurable as well, so we will start with some | |
|
22 | application-level config. | |
|
26 | 23 | |
|
27 |
|
|
|
28 | ==================== | |
|
24 | Application-level configuration | |
|
25 | =============================== | |
|
29 | 26 | |
|
30 | 27 | Assuming that your configuration file has the following at the top:: |
|
31 | 28 | |
|
32 | 29 | c = get_config() |
|
33 | 30 | |
|
34 |
the following attributes |
|
|
31 | the following attributes are set application-wide: | |
|
35 | 32 | |
|
36 | :attr:`c.IPythonApp.display_banner` | |
|
33 | terminal IPython-only flags: | |
|
34 | ||
|
35 | :attr:`c.TerminalIPythonApp.display_banner` | |
|
37 | 36 | A boolean that determined if the banner is printer when :command:`ipython` |
|
38 | 37 | is started. |
|
39 | 38 | |
|
40 | :attr:`c.IPythonApp.classic` | |
|
39 | :attr:`c.TerminalIPythonApp.classic` | |
|
41 | 40 | A boolean that determines if IPython starts in "classic" mode. In this |
|
42 | 41 | mode, the prompts and everything mimic that of the normal :command:`python` |
|
43 | 42 | shell |
|
44 | 43 | |
|
45 | :attr:`c.IPythonApp.nosep` | |
|
44 | :attr:`c.TerminalIPythonApp.nosep` | |
|
46 | 45 | A boolean that determines if there should be no blank lines between |
|
47 | 46 | prompts. |
|
48 | 47 | |
|
49 |
:attr:`c. |
|
|
48 | :attr:`c.Application.log_level` | |
|
50 | 49 | An integer that sets the detail of the logging level during the startup |
|
51 | 50 | of :command:`ipython`. The default is 30 and the possible values are |
|
52 | 51 | (0, 10, 20, 30, 40, 50). Higher is quieter and lower is more verbose. |
|
52 | This can also be set by the name of the logging level, e.g. INFO=20, | |
|
53 | WARN=30. | |
|
54 | ||
|
55 | Some options, such as extensions and startup code, can be set for any | |
|
56 | application that starts an | |
|
57 | :class:`~IPython.core.interactiveshell.InteractiveShell`. These apps are | |
|
58 | subclasses of :class:`~IPython.core.shellapp.InteractiveShellApp`. Since | |
|
59 | subclasses inherit configuration, setting a trait of | |
|
60 | :attr:`c.InteractiveShellApp` will affect all IPython applications, but if you | |
|
61 | want terminal IPython and the QtConsole to have different values, you can set | |
|
62 | them via :attr:`c.TerminalIPythonApp` and :attr:`c.IPKernelApp` respectively. | |
|
63 | ||
|
53 | 64 | |
|
54 |
:attr:`c.I |
|
|
65 | :attr:`c.InteractiveShellApp.extensions` | |
|
55 | 66 | A list of strings, each of which is an importable IPython extension. An |
|
56 | 67 | IPython extension is a regular Python module or package that has a |
|
57 | 68 | :func:`load_ipython_extension(ip)` method. This method gets called when |
|
58 | 69 | the extension is loaded with the currently running |
|
59 |
:class:`~IPython.core.i |
|
|
60 |
can put your extensions anywhere they can be imported but we |
|
|
61 |
:file:`extensions` subdirectory of the ipython directory to |
|
|
62 |
during extension loading, so you can put them there as well. |
|
|
63 |
are not executed in the user's interactive namespace and they |
|
|
64 | Python code. Extensions are the recommended way of customizing | |
|
70 | :class:`~IPython.core.interactiveshell.InteractiveShell` as its only | |
|
71 | argument. You can put your extensions anywhere they can be imported but we | |
|
72 | add the :file:`extensions` subdirectory of the ipython directory to | |
|
73 | ``sys.path`` during extension loading, so you can put them there as well. | |
|
74 | Extensions are not executed in the user's interactive namespace and they | |
|
75 | must be pure Python code. Extensions are the recommended way of customizing | |
|
65 | 76 | :command:`ipython`. Extensions can provide an |
|
66 | 77 | :func:`unload_ipython_extension` that will be called when the extension is |
|
67 | 78 | unloaded. |
|
68 | 79 | |
|
69 |
:attr:`c.I |
|
|
80 | :attr:`c.InteractiveShellApp.exec_lines` | |
|
70 | 81 | A list of strings, each of which is Python code that is run in the user's |
|
71 | 82 | namespace after IPython start. These lines can contain full IPython syntax |
|
72 | 83 | with magics, etc. |
|
73 | 84 | |
|
74 |
:attr:`c.I |
|
|
85 | :attr:`c.InteractiveShellApp.exec_files` | |
|
75 | 86 | A list of strings, each of which is the full pathname of a ``.py`` or |
|
76 | 87 | ``.ipy`` file that will be executed as IPython starts. These files are run |
|
77 | 88 | in IPython in the user's namespace. Files with a ``.py`` extension need to |
@@ -85,7 +96,7 b' Classes that can be configured' | |||
|
85 | 96 | The following classes can also be configured in the configuration file for |
|
86 | 97 | :command:`ipython`: |
|
87 | 98 | |
|
88 |
* :class:`~IPython.core.i |
|
|
99 | * :class:`~IPython.core.interactiveshell.InteractiveShell` | |
|
89 | 100 | |
|
90 | 101 | * :class:`~IPython.core.prefilter.PrefilterManager` |
|
91 | 102 | |
@@ -105,16 +116,16 b' attributes::' | |||
|
105 | 116 | # sample ipython_config.py |
|
106 | 117 | c = get_config() |
|
107 | 118 | |
|
108 | c.IPythonApp.display_banner = True | |
|
109 |
c.I |
|
|
110 |
c.I |
|
|
119 | c.IPythonTerminalApp.display_banner = True | |
|
120 | c.InteractiveShellApp.log_level = 20 | |
|
121 | c.InteractiveShellApp.extensions = [ | |
|
111 | 122 | 'myextension' |
|
112 | 123 | ] |
|
113 |
c.I |
|
|
124 | c.InteractiveShellApp.exec_lines = [ | |
|
114 | 125 | 'import numpy', |
|
115 | 126 | 'import scipy' |
|
116 | 127 | ] |
|
117 |
c.I |
|
|
128 | c.InteractiveShellApp.exec_files = [ | |
|
118 | 129 | 'mycode.py', |
|
119 | 130 | 'fancy.ipy' |
|
120 | 131 | ] |
@@ -18,8 +18,8 b' met our requirements.' | |||
|
18 | 18 | your old :file:`ipythonrc` or :file:`ipy_user_conf.py` configuration files |
|
19 | 19 | to the new system. Read on for information on how to do this. |
|
20 | 20 | |
|
21 |
The discussion that follows is focused on teaching user |
|
|
22 |
IPython to their liking. Developer |
|
|
21 | The discussion that follows is focused on teaching users how to configure | |
|
22 | IPython to their liking. Developers who want to know more about how they | |
|
23 | 23 | can enable their objects to take advantage of the configuration system |
|
24 | 24 | should consult our :ref:`developer guide <developer_guide>` |
|
25 | 25 | |
@@ -37,16 +37,20 b' Configuration object: :class:`~IPython.config.loader.Config`' | |||
|
37 | 37 | are smart. They know how to merge themselves with other configuration |
|
38 | 38 | objects and they automatically create sub-configuration objects. |
|
39 | 39 | |
|
40 |
Application: :class:`~IPython.co |
|
|
40 | Application: :class:`~IPython.config.application.Application` | |
|
41 | 41 | An application is a process that does a specific job. The most obvious |
|
42 | 42 | application is the :command:`ipython` command line program. Each |
|
43 |
application reads |
|
|
43 | application reads *one or more* configuration files and a single set of | |
|
44 | command line options | |
|
44 | 45 | and then produces a master configuration object for the application. This |
|
45 | 46 | configuration object is then passed to the configurable objects that the |
|
46 | 47 | application creates. These configurable objects implement the actual logic |
|
47 | 48 | of the application and know how to configure themselves given the |
|
48 | 49 | configuration object. |
|
49 | 50 | |
|
51 | Applications always have a `log` attribute that is a configured Logger. | |
|
52 | This allows centralized logging configuration per-application. | |
|
53 | ||
|
50 | 54 | Component: :class:`~IPython.config.configurable.Configurable` |
|
51 | 55 | A configurable is a regular Python class that serves as a base class for |
|
52 | 56 | all main classes in an application. The |
@@ -64,6 +68,25 b' Component: :class:`~IPython.config.configurable.Configurable`' | |||
|
64 | 68 | these subclasses has its own configuration information that controls how |
|
65 | 69 | instances are created. |
|
66 | 70 | |
|
71 | Singletons: :class:`~IPython.config.configurable.SingletonConfigurable` | |
|
72 | Any object for which there is a single canonical instance. These are | |
|
73 | just like Configurables, except they have a class method | |
|
74 | :meth:`~IPython.config.configurable.SingletonConfigurable.instance`, | |
|
75 | that returns the current active instance (or creates one if it | |
|
76 | does not exist). Examples of singletons include | |
|
77 | :class:`~IPython.config.application.Application`s and | |
|
78 | :class:`~IPython.core.interactiveshell.InteractiveShell`. This lets | |
|
79 | objects easily connect to the current running Application without passing | |
|
80 | objects around everywhere. For instance, to get the current running | |
|
81 | Application instance, simply do: ``app = Application.instance()``. | |
|
82 | ||
|
83 | ||
|
84 | .. note:: | |
|
85 | ||
|
86 | Singletons are not strictly enforced - you can have many instances | |
|
87 | of a given singleton class, but the :meth:`instance` method will always | |
|
88 | return the same one. | |
|
89 | ||
|
67 | 90 | Having described these main concepts, we can now state the main idea in our |
|
68 | 91 | configuration system: *"configuration" allows the default values of class |
|
69 | 92 | attributes to be controlled on a class by class basis*. Thus all instances of |
@@ -106,7 +129,7 b' subclass::' | |||
|
106 | 129 | from IPython.utils.traitlets import Int, Float, Str, Bool |
|
107 | 130 | |
|
108 | 131 | class MyClass(Configurable): |
|
109 |
name = |
|
|
132 | name = Unicode(u'defaultname', config=True) | |
|
110 | 133 | ranking = Int(0, config=True) |
|
111 | 134 | value = Float(99.0) |
|
112 | 135 | # The rest of the class implementation would go here.. |
@@ -197,6 +220,15 b' search path for sub-configuration files is inherited from that of the parent.' | |||
|
197 | 220 | Thus, you can typically put the two in the same directory and everything will |
|
198 | 221 | just work. |
|
199 | 222 | |
|
223 | You can also load configuration files by profile, for instance: | |
|
224 | ||
|
225 | .. sourcecode:: python | |
|
226 | ||
|
227 | load_subconfig('ipython_config.py', profile='default') | |
|
228 | ||
|
229 | to inherit your default configuration as a starting point. | |
|
230 | ||
|
231 | ||
|
200 | 232 | Class based configuration inheritance |
|
201 | 233 | ===================================== |
|
202 | 234 | |
@@ -241,9 +273,10 b' This class hierarchy and configuration file accomplishes the following:' | |||
|
241 | 273 | Configuration file location |
|
242 | 274 | =========================== |
|
243 | 275 | |
|
244 |
So where should you put your configuration files? |
|
|
245 | applications look in the so called "IPython directory". The location of | |
|
246 | this directory is determined by the following algorithm: | |
|
276 | So where should you put your configuration files? IPython uses "profiles" for | |
|
277 | configuration, and by default, all profiles will be stored in the so called | |
|
278 | "IPython directory". The location of this directory is determined by the | |
|
279 | following algorithm: | |
|
247 | 280 | |
|
248 | 281 | * If the ``ipython_dir`` command line flag is given, its value is used. |
|
249 | 282 | |
@@ -263,26 +296,41 b' For most users, the default value will simply be something like' | |||
|
263 | 296 | :file:`$HOME/.config/ipython` on Linux, or :file:`$HOME/.ipython` |
|
264 | 297 | elsewhere. |
|
265 | 298 | |
|
266 | Once the location of the IPython directory has been determined, you need to | |
|
267 | know what filename to use for the configuration file. The basic idea is that | |
|
268 | each application has its own default configuration filename. The default named | |
|
269 | used by the :command:`ipython` command line program is | |
|
270 | :file:`ipython_config.py`. This value can be overriden by the ``config_file`` | |
|
271 | command line flag. A sample :file:`ipython_config.py` file can be found | |
|
272 | in :mod:`IPython.config.default.ipython_config.py`. Simple copy it to your | |
|
273 | IPython directory to begin using it. | |
|
299 | Once the location of the IPython directory has been determined, you need to know | |
|
300 | which profile you are using. For users with a single configuration, this will | |
|
301 | simply be 'default', and will be located in | |
|
302 | :file:`<IPYTHON_DIR>/profile_default`. | |
|
303 | ||
|
304 | The next thing you need to know is what to call your configuration file. The | |
|
305 | basic idea is that each application has its own default configuration filename. | |
|
306 | The default named used by the :command:`ipython` command line program is | |
|
307 | :file:`ipython_config.py`, and *all* IPython applications will use this file. | |
|
308 | Other applications, such as the parallel :command:`ipcluster` scripts or the | |
|
309 | QtConsole will load their own config files *after* :file:`ipython_config.py`. To | |
|
310 | load a particular configuration file instead of the default, the name can be | |
|
311 | overridden by the ``config_file`` command line flag. | |
|
312 | ||
|
313 | To generate the default configuration files, do:: | |
|
314 | ||
|
315 | $> ipython profile create | |
|
316 | ||
|
317 | and you will have a default :file:`ipython_config.py` in your IPython directory | |
|
318 | under :file:`profile_default`. If you want the default config files for the | |
|
319 | :mod:`IPython.parallel` applications, add ``--parallel`` to the end of the | |
|
320 | command-line args. | |
|
274 | 321 | |
|
275 | 322 | .. _Profiles: |
|
276 | 323 | |
|
277 | 324 | Profiles |
|
278 | 325 | ======== |
|
279 | 326 | |
|
280 | A profile is simply a configuration file that follows a simple naming | |
|
281 | convention and can be loaded using a simplified syntax. The idea is | |
|
282 | that users often want to maintain a set of configuration files for different | |
|
283 | purposes: one for doing numerical computing with NumPy and SciPy and | |
|
284 | another for doing symbolic computing with SymPy. Profiles make it easy | |
|
285 | to keep a separate configuration file for each of these purposes. | |
|
327 | A profile is a directory containing configuration and runtime files, such as | |
|
328 | logs, connection info for the parallel apps, and your IPython command history. | |
|
329 | ||
|
330 | The idea is that users often want to maintain a set of configuration files for | |
|
331 | different purposes: one for doing numerical computing with NumPy and SciPy and | |
|
332 | another for doing symbolic computing with SymPy. Profiles make it easy to keep a | |
|
333 | separate configuration files, logs, and histories for each of these purposes. | |
|
286 | 334 | |
|
287 | 335 | Let's start by showing how a profile is used: |
|
288 | 336 | |
@@ -290,18 +338,107 b" Let's start by showing how a profile is used:" | |||
|
290 | 338 | |
|
291 | 339 | $ ipython profile=sympy |
|
292 | 340 | |
|
293 | This tells the :command:`ipython` command line program to get its | |
|
294 |
|
|
|
295 | same as that of regular configuration files. The only difference is that | |
|
296 | profiles are named in a special way. In the case above, the "sympy" profile | |
|
297 | would need to have the name :file:`ipython_config_sympy.py`. | |
|
341 | This tells the :command:`ipython` command line program to get its configuration | |
|
342 | from the "sympy" profile. The file names for various profiles do not change. The | |
|
343 | only difference is that profiles are named in a special way. In the case above, | |
|
344 | the "sympy" profile means looking for :file:`ipython_config.py` in :file:`<IPYTHON_DIR>/profile_sympy`. | |
|
345 | ||
|
346 | The general pattern is this: simply create a new profile with: | |
|
347 | ||
|
348 | .. code-block:: bash | |
|
349 | ||
|
350 | ipython profile create <name> | |
|
351 | ||
|
352 | which adds a directory called ``profile_<name>`` to your IPython directory. Then | |
|
353 | you can load this profile by adding ``profile=<name>`` to your command line | |
|
354 | options. Profiles are supported by all IPython applications. | |
|
355 | ||
|
356 | IPython ships with some sample profiles in :file:`IPython/config/profile`. If | |
|
357 | you create profiles with the name of one of our shipped profiles, these config | |
|
358 | files will be copied over instead of starting with the automatically generated | |
|
359 | config files. | |
|
360 | ||
|
361 | .. _commandline: | |
|
362 | ||
|
363 | Command-line arguments | |
|
364 | ====================== | |
|
365 | ||
|
366 | IPython exposes *all* configurable options on the command-line. The command-line | |
|
367 | arguments are generated from the Configurable traits of the classes associated | |
|
368 | with a given Application. Configuring IPython from the command-line may look | |
|
369 | very similar to an IPython config file | |
|
370 | ||
|
371 | IPython applications use a parser called | |
|
372 | :class:`~IPython.config.loader.KeyValueLoader` to load values into a Config | |
|
373 | object. Values are assigned in much the same way as in a config file: | |
|
374 | ||
|
375 | .. code-block:: bash | |
|
376 | ||
|
377 | $> ipython InteractiveShell.use_readline=False BaseIPythonApplication.profile='myprofile' | |
|
378 | ||
|
379 | Is the same as adding: | |
|
380 | ||
|
381 | .. sourcecode:: python | |
|
382 | ||
|
383 | c.InteractiveShell.use_readline=False | |
|
384 | c.BaseIPythonApplication.profile='myprofile' | |
|
385 | ||
|
386 | to your config file. Key/Value arguments *always* take a value, separated by '=' | |
|
387 | and no spaces. | |
|
388 | ||
|
389 | Aliases | |
|
390 | ------- | |
|
391 | ||
|
392 | For convenience, applications have a mapping of commonly | |
|
393 | used traits, so you don't have to specify the whole class name. For these **aliases**, the class need not be specified: | |
|
394 | ||
|
395 | .. code-block:: bash | |
|
396 | ||
|
397 | $> ipython profile='myprofile' | |
|
398 | # is equivalent to | |
|
399 | $> ipython BaseIPythonApplication.profile='myprofile' | |
|
400 | ||
|
401 | Flags | |
|
402 | ----- | |
|
403 | ||
|
404 | Applications can also be passed **flags**. Flags are options that take no | |
|
405 | arguments, and are always prefixed with ``--``. They are simply wrappers for | |
|
406 | setting one or more configurables with predefined values, often True/False. | |
|
407 | ||
|
408 | For instance: | |
|
409 | ||
|
410 | .. code-block:: bash | |
|
411 | ||
|
412 | $> ipcontroller --debug | |
|
413 | # is equivalent to | |
|
414 | $> ipcontroller Application.log_level=DEBUG | |
|
415 | # and | |
|
416 | $> ipython --pylab | |
|
417 | # is equivalent to | |
|
418 | $> ipython pylab=auto | |
|
419 | ||
|
420 | Subcommands | |
|
421 | ----------- | |
|
422 | ||
|
423 | ||
|
424 | Some IPython applications have **subcommands**. Subcommands are modeled after | |
|
425 | :command:`git`, and are called with the form :command:`command subcommand | |
|
426 | [...args]`. Currently, the QtConsole is a subcommand of terminal IPython: | |
|
427 | ||
|
428 | .. code-block:: bash | |
|
429 | ||
|
430 | $> ipython qtconsole profile=myprofile | |
|
431 | ||
|
432 | and :command:`ipcluster` is simply a wrapper for its various subcommands (start, | |
|
433 | stop, engines). | |
|
434 | ||
|
435 | .. code-block:: bash | |
|
436 | ||
|
437 | $> ipcluster start profile=myprofile n=4 | |
|
438 | ||
|
298 | 439 | |
|
299 | The general pattern is this: simply add ``<profilename>`` to the end of the | |
|
300 | normal configuration file name. Then load the profile by adding | |
|
301 | ``profile=<profilename>`` to your command line options. | |
|
440 | To see a list of the available aliases, flags, and subcommands for an IPython application, simply pass ``-h`` or ``--help``. And to see the full list of configurable options (*very* long), pass ``--help-all``. | |
|
302 | 441 | |
|
303 | IPython ships with some sample profiles in :mod:`IPython.config.profile`. | |
|
304 | Simply copy these to your IPython directory to begin using them. | |
|
305 | 442 | |
|
306 | 443 | Design requirements |
|
307 | 444 | =================== |
General Comments 0
You need to be logged in to leave comments.
Login now