Commit d6dcdd8f authored by Reinout van Rees's avatar Reinout van Rees Committed by GitHub

Merge pull request #439 from nlsdfnbch/patch-3

Clarify intent plus spelling/grammar fixes
parents da40fdb6 a2f357f9
...@@ -322,7 +322,7 @@ More than just a package installer ...@@ -322,7 +322,7 @@ More than just a package installer
================================== ==================================
The example shown above illustrates how Buildout is more than just a The example shown above illustrates how Buildout is more than just a
package installer, like ``pip``. Using Buildout recipes, we can package installer such as ``pip``. Using Buildout recipes, we can
install custom scripts and configuration files, and much more. For install custom scripts and configuration files, and much more. For
example, we could use `configure and make example, we could use `configure and make
<https://pypi.python.org/pypi/zc.recipe.cmmi>`_ to install non-Python <https://pypi.python.org/pypi/zc.recipe.cmmi>`_ to install non-Python
...@@ -349,7 +349,7 @@ Buildout environment ...@@ -349,7 +349,7 @@ Buildout environment
-------------------- --------------------
A Buildout environment includes the operating system and the Python A Buildout environment includes the operating system and the Python
installation it's run with. The more a buildout depends on its installation Buildout is run with. The more a buildout depends on its
environment, the more variation is likely between builds. environment, the more variation is likely between builds.
If a Python installation is shared, packages installed by one If a Python installation is shared, packages installed by one
...@@ -405,7 +405,7 @@ run without this option. ...@@ -405,7 +405,7 @@ run without this option.
Pinned versions Pinned versions
_______________ _______________
You can also pin required versions in two ways. You can specify them You can also pin required versions, and do so in two ways. You can specify them
where you list them, as in: where you list them, as in:
.. code-block:: ini .. code-block:: ini
...@@ -432,7 +432,7 @@ where you list them, as in: ...@@ -432,7 +432,7 @@ where you list them, as in:
In this example, we've requested a version of bobo less than 5.0. In this example, we've requested a version of bobo less than 5.0.
The more common way to pin version is using a ``versions`` section: The more common way to pin a version is using a ``versions`` section:
.. code-block:: ini .. code-block:: ini
...@@ -462,7 +462,7 @@ The more common way to pin version is using a ``versions`` section: ...@@ -462,7 +462,7 @@ The more common way to pin version is using a ``versions`` section:
>>> nope('bobo = 2.3.0' in read('out')) >>> nope('bobo = 2.3.0' in read('out'))
Larger projects may need to pin many versions, so it's common to put Larger projects may need to pin many versions, so it's common to put
versions in their own file: version requirements in their own file:
.. code-block:: ini .. code-block:: ini
...@@ -486,9 +486,12 @@ versions in their own file: ...@@ -486,9 +486,12 @@ versions in their own file:
>>> write(src, 'buildout.cfg') >>> write(src, 'buildout.cfg')
Here, we've used the Buildout ``extends`` option to say that Here, we've used the Buildout ``extends`` option to say that
configurations should be read from the named file (or files) and that configurations should be read from ``versions.cfg`` (it's
allowed to specify several files in ``extend``). Cconfigurations
should be read from the named file (or files) and the
configuration in the current file should override configuration in the configuration in the current file should override configuration in the
extended files. To continue the example, our ``versions.cfg`` file extended files.
To continue the example, our ``versions.cfg`` file
might look like: might look like:
.. code-block:: ini .. code-block:: ini
...@@ -539,7 +542,7 @@ With ``update-versions-file``, whenever Buildout gets the newest ...@@ -539,7 +542,7 @@ With ``update-versions-file``, whenever Buildout gets the newest
version for a requirement (subject to requirement constraints), it version for a requirement (subject to requirement constraints), it
appends the version to the named file, along with a comment saying appends the version to the named file, along with a comment saying
when and why the requirement is installed. If you later want to when and why the requirement is installed. If you later want to
upgrade a dependency, just edit this file with the new version, or to upgrade a dependency, edi this file with the new version. Alternatively,
remove the entry altogether and Buildout will add a new entry the next remove the entry altogether and Buildout will add a new entry the next
time it runs. time it runs.
...@@ -560,10 +563,10 @@ integration tests, you want to be sure that you can reproduce the ...@@ -560,10 +563,10 @@ integration tests, you want to be sure that you can reproduce the
tested configuration. tested configuration.
You shouldn't pin versions for a component, such as a library, because You shouldn't pin versions for a component, such as a library, because
doing so inhibits the ability for users of your component to integrate it doing so inhibits the ability of users of your component to integrate it
with their dependencies, which may overlap with yours. If you know with their dependencies, which may overlap with yours. If you know
that your component only works a range of versions of some dependency, that your component only works for a specific range of versions of some dependency,
the express the range in your project requirements. Don't require set the range in your project requirements. Don't require
specific versions. specific versions.
.. _unpinning-versions: .. _unpinning-versions:
...@@ -642,7 +645,7 @@ facilitates this with the ``develop`` option: ...@@ -642,7 +645,7 @@ facilitates this with the ``develop`` option:
.. -> develop_snippet .. -> develop_snippet
The ``develop`` option takes one more more paths to project `setup.py The ``develop`` option takes one or more paths to project `setup.py
<https://docs.python.org/3.6/distutils/setupscript.html>`_ files or, <https://docs.python.org/3.6/distutils/setupscript.html>`_ files or,
more commonly, directories containing them. Buildout then creates more commonly, directories containing them. Buildout then creates
"develop eggs" [#develop-eggs]_ for the corresponding projects. "develop eggs" [#develop-eggs]_ for the corresponding projects.
...@@ -676,7 +679,7 @@ example:: ...@@ -676,7 +679,7 @@ example::
>>> write(src, 'setup.py') >>> write(src, 'setup.py')
We suggest copying and modifying the example above, using it as We suggest copying and modifying the example above, using it as
boilerplate. As is probably clear, the setup arguments used: boilerplate. As is probably clear, the setup arguments used are:
name name
The name of your application. This is the name you'll use in The name of your application. This is the name you'll use in
...@@ -760,7 +763,7 @@ details, as well as let you know about features not touched on here. ...@@ -760,7 +763,7 @@ details, as well as let you know about features not touched on here.
more in the topic on :ref:`Buildout and packaging more in the topic on :ref:`Buildout and packaging
<buildout_and_packaging>`. <buildout_and_packaging>`.
.. [#configparser] Buildout uses a variation (fork) of standard .. [#configparser] Buildout uses a variation (fork) of the standard
``ConfigParser`` module and follows (mostly) the same parsing ``ConfigParser`` module and follows (mostly) the same parsing
rules. rules.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment