update doc
This commit is contained in:
parent
b92c087cfc
commit
73e32af95d
6 changed files with 10 additions and 31 deletions
|
@ -50,7 +50,7 @@ copyright = u'2013, tiramisu team'
|
|||
# The short X.Y version.
|
||||
version = '1'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '1.0RC1'
|
||||
release = '1.0'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
|
|
@ -27,8 +27,6 @@ object is returned, and if no `Option` has been declared in the
|
|||
::
|
||||
|
||||
>>> gcdummy = BoolOption('dummy', 'dummy', default=False)
|
||||
>>> gcdummy._name
|
||||
'dummy'
|
||||
>>> gcdummy.getdefault()
|
||||
False
|
||||
>>> descr = OptionDescription('tiramisu', '', [gcdummy])
|
||||
|
|
|
@ -52,13 +52,13 @@ to carry out a dependencies calculation. For example, an option can ben
|
|||
hidden if another option has been set with some expected value. This is
|
||||
just an example, the possibilities are hudge.
|
||||
|
||||
A requirement is a list of dictionnaries that have fairly this form::
|
||||
A requirement is a list of dictionaries that have fairly this form::
|
||||
|
||||
[{'option': a, 'expected': False, 'action': 'disabled', 'inverse': True,
|
||||
'transitive':True, 'same_action': True}]
|
||||
|
||||
Actually a transformation is made to this dictionnary during the validation of
|
||||
this requires at the :class:`~option.Option()`'s init. The dictionnairy becomes
|
||||
Actually a transformation is made to this dictionary during the validation of
|
||||
this requires at the :class:`~option.Option()`'s init. The dictionairy becomes
|
||||
a tuple, wich is passed to the :meth:`~setting.Settings.apply_requires()`
|
||||
method. Take a look at the code to fully understand the exact meaning of the
|
||||
requirements:
|
||||
|
|
|
@ -6,7 +6,7 @@ What is options handling ?
|
|||
=================================
|
||||
|
||||
Due to more and more available options required to set up an operating system,
|
||||
to set up compiler options, vs... it became quite annoying to hand the
|
||||
to set up compiler options, and so on. it became quite annoying to hand the
|
||||
necessary options to where they are actually used and even more annoying to add
|
||||
new options. To circumvent these problems the configuration management was
|
||||
introduced...
|
||||
|
|
|
@ -25,29 +25,10 @@ The `OptionDescription` class
|
|||
:members:
|
||||
|
||||
|
||||
If you need to access an option object, you can do it with the OptionDescription
|
||||
object. Not only the value of the option by attribute access, but the option
|
||||
object itself that lives behind the scene. It can always be accessed internally
|
||||
with the `impl_descr` attribute of the `config` objects. For example, with a
|
||||
option named `name` in a `gc` group the `name` object can be accessed like
|
||||
this::
|
||||
|
||||
conf._impl_descr.name
|
||||
|
||||
of sub configs with ::
|
||||
|
||||
conf.gc._impl_descr.name
|
||||
|
||||
This is a binding. The option objects are in the `_children` config's attribute.
|
||||
|
||||
Why accessing an option object ? It is possible for example freeze the
|
||||
configuration option
|
||||
|
||||
::
|
||||
|
||||
conf.gc._impl_descr.dummy.freeze()
|
||||
|
||||
or to hide it, or disable it, or... anything.
|
||||
If you need to access an option object, you can do it with the OptionDescription
|
||||
object. Not only the value of the option by attribute access, but the option
|
||||
object itself that lives behind the scene. It can always be accessed internally.
|
||||
The option objects are in the `_children` `OptionDescription`'s attribute.
|
||||
|
||||
The `Option` base class
|
||||
-------------------------
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
.. default-role:: literal
|
||||
|
||||
Local statuses and global setting
|
||||
Local statuses and global settings
|
||||
=====================================
|
||||
|
||||
Available configuration statuses
|
||||
|
|
Loading…
Reference in a new issue