update doc

This commit is contained in:
gwen 2013-08-28 09:22:44 +02:00
parent b92c087cfc
commit 73e32af95d
6 changed files with 10 additions and 31 deletions

View file

@ -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.

View file

@ -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])

View file

@ -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:

View file

@ -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...

View file

@ -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
-------------------------

View file

@ -1,6 +1,6 @@
.. default-role:: literal
Local statuses and global setting
Local statuses and global settings
=====================================
Available configuration statuses