[Checkins] SVN: zc.buildout/branches/amos-dependency-links/ * Made
relationship between dependency_links and find_links clearer.
Amos Latteier
amos at latteier.com
Sat Oct 20 15:22:15 EDT 2007
Log message for revision 80951:
* Made relationship between dependency_links and find_links clearer.
* Improved coverage of tests.
* Fixed some typos.
Changed:
U zc.buildout/branches/amos-dependency-links/CHANGES.txt
U zc.buildout/branches/amos-dependency-links/src/zc/buildout/buildout.txt
U zc.buildout/branches/amos-dependency-links/src/zc/buildout/easy_install.txt
-=-
Modified: zc.buildout/branches/amos-dependency-links/CHANGES.txt
===================================================================
--- zc.buildout/branches/amos-dependency-links/CHANGES.txt 2007-10-20 15:35:06 UTC (rev 80950)
+++ zc.buildout/branches/amos-dependency-links/CHANGES.txt 2007-10-20 19:22:14 UTC (rev 80951)
@@ -19,9 +19,9 @@
- Added a configuration option that allows buildouts to ignore
dependency_links metadata specified in setup. By default
- dependency_links in setup are used in preference to buildout
- specified find-links. This can make it hard to control where eggs
- come from. Here's how to tell buildout to ignore URLs in
+ dependency_links in setup are used in addition to buildout specified
+ find-links. This can make it hard to control where eggs come
+ from. Here's how to tell buildout to ignore URLs in
dependency_links::
[buildout]
Modified: zc.buildout/branches/amos-dependency-links/src/zc/buildout/buildout.txt
===================================================================
--- zc.buildout/branches/amos-dependency-links/src/zc/buildout/buildout.txt 2007-10-20 15:35:06 UTC (rev 80950)
+++ zc.buildout/branches/amos-dependency-links/src/zc/buildout/buildout.txt 2007-10-20 19:22:14 UTC (rev 80951)
@@ -154,7 +154,7 @@
The constructor is responsible for updating a parts options to reflect
data read from other sections. The buildout system keeps track of
whether a part specification has changed. A part specification has
-changed if it's options, after ajusting for data read from other
+changed if it's options, after adjusting for data read from other
sections, has changed, or if the recipe has changed. Only the options
for the part are considered. If data are read from other sections,
then that information has to be reflected in the parts options. In
@@ -174,7 +174,7 @@
buildout only looks at the part's options, so any data used to
configure the part needs to be reflected in the part's options. It is
the job of a recipe constructor to make sure that the options include
-all relevent data.
+all relevant data.
Of course, parts are also uninstalled if they are no-longer used.
@@ -368,7 +368,7 @@
zc.buildout.UserError exception. Raising an error other than a
UserError still displays the error, but labels it as a bug in the
buildout software or recipe. In the sample above, of someone gives a
-non-existant directory to create the directory in:
+non-existent directory to create the directory in:
>>> write(sample_buildout, 'buildout.cfg',
@@ -464,7 +464,7 @@
OSError:
[Errno 17] File exists: '/sample-buildout/bin'
-We meant to create a directiry bins, but typed bin. Now foo was
+We meant to create a directory bins, but typed bin. Now foo was
left behind.
>>> os.path.exists('foo')
@@ -582,7 +582,7 @@
occur. Because recipes most commonly create files and directories,
buildout provides a helper API for removing created files when an
error occurs. Option objects have a created method that can be called
-to record files as they are created. If the install or update methof
+to record files as they are created. If the install or update method
returns with an error, then any registered paths are removed
automatically. The method returns the files registered and can be
used to return the files created. Let's use this API to simplify the
@@ -633,7 +633,7 @@
It would be simpler just to return the paths as before.
If we rerun the buildout, again, we'll get the error and no
-directiories will be created:
+directories will be created:
>>> print system(buildout),
Develop: '/sample-buildout/recipes'
@@ -685,7 +685,7 @@
- option names are case sensitive
-- option values can ue a substitution syntax, described below, to
+- option values can use a substitution syntax, described below, to
refer to option values in specific sections.
The ConfigParser syntax is very flexible. Section names can contain
@@ -821,7 +821,7 @@
Automatic part selection and ordering
-------------------------------------
-When a section with a recipe is refered to, either through variable
+When a section with a recipe is referred to, either through variable
substitution or by an initializing recipe, the section is treated as a
part and added to the part list before the referencing part. For
example, we can leave data-dir out of the parts list:
@@ -1076,7 +1076,7 @@
recipe recipes:debug
Here we specified a URL for the file we extended. The file we
-downloaded, itself refered to a file on the server using a relative
+downloaded, itself referred to a file on the server using a relative
URL reference. Relative references are interpreted relative to the
base URL when they appear in configuration files loaded via URL.
@@ -1282,7 +1282,7 @@
<BLANKLINE>
The service has been installed. If the buildout is run again with no
-changes, the serivce shouldn't be changed.
+changes, the service shouldn't be changed.
>>> print system(buildout)
Develop: '/sample-buildout/recipes'
@@ -1424,7 +1424,7 @@
recipe recipes:debug
<BLANKLINE>
-Now we will return the registeration to normal for the benefit of the
+Now we will return the registration to normal for the benefit of the
rest of the examples.
>>> write(sample_buildout, 'recipes', 'setup.py',
@@ -2004,7 +2004,7 @@
- setuptools-0.6-py2.3.egg
- zc.buildout-1.0-py2.3.egg
-(We list both the eggs and develop-eggs diectories because the
+(We list both the eggs and develop-eggs directories because the
buildout or setuptools egg could be installed in the develop-eggs
directory if the original buildout had develop eggs for either
buildout or setuptools.)
@@ -2060,35 +2060,35 @@
makes buildouts run much faster. This option is typically set using
the buildout -o option.
-Prefering Final Releases
-------------------------
+Preferring Final Releases
+-------------------------
Currently, when searching for new releases, the newest available
-release is used. This isn't usually ideal, as you may get development
-releaes or alpha releases not ready to be widely used. You can
-request that final releases be prefered using the prefer final option
-in the buildout section::
+release is used. This isn't usually ideal, as you may get a
+development release or alpha releases not ready to be widely used.
+You can request that final releases be preferred using the prefer
+final option in the buildout section::
[buildout]
...
prefer-final = true
When the prefer-final option is set to true, then when searching for
-new releases, final releases are prefered. If there are final
+new releases, final releases are preferred. If there are final
releases that satisfy distribution requirements, then those releases
are used even if newer non-final releases are available. The buildout
prefer-final option can be used to override this behavior.
-In buildout version 2, final releases will be prefered by default.
+In buildout version 2, final releases will be preferred by default.
You will then need to use a false value for prefer-final to get the
-newset releases.
+newest releases.
Dependency links
----------------
By default buildout will obey the setuptools dependency_links metadata
when it looks for dependencies. This behavior can be controlled with
-the use-dependency-links buildout option.
+the use-dependency-links buildout option::
[buildout]
...
@@ -2097,13 +2097,12 @@
The option defaults to true. If you set it to false, then dependency
links are only looked for in the locations specified by find-links.
-
Controlling the installation database
-------------------------------------
-The buildout installed uption is used to specify the file used to save
+The buildout installed option is used to specify the file used to save
information on installed parts. This option is initialized to
-".installed.cfg", but it can be overridded in the configuration file
+".installed.cfg", but it can be overridden in the configuration file
or on the command line:
>>> write('buildout.cfg',
@@ -2134,7 +2133,7 @@
d recipes
The installation database can be disabled by supplying an empty
-buildout installed opttion:
+buildout installed option:
>>> os.remove('inst.cfg')
>>> print system(buildout+' buildout:installed='),
@@ -2227,7 +2226,7 @@
>>> print system(os.path.join(sample_bootstrapped, 'bin', 'buildout')),
Develop: '/sample-bootstrapped/demo'
-Now we can add the extensions option. We were a bit tricly and ran
+Now we can add the extensions option. We were a bit tricky and ran
the buildout once with the demo develop egg defined but without the
extension option. This is because extensions are loaded before the
buildout creates develop eggs. We needed to use a separate buildout
@@ -2250,7 +2249,7 @@
-.. [#future_recipe_methods] In the future, additional mathods may be
+.. [#future_recipe_methods] In the future, additional methods may be
added. Older recipes with fewer methods will still be
supported.
Modified: zc.buildout/branches/amos-dependency-links/src/zc/buildout/easy_install.txt
===================================================================
--- zc.buildout/branches/amos-dependency-links/src/zc/buildout/easy_install.txt 2007-10-20 15:35:06 UTC (rev 80950)
+++ zc.buildout/branches/amos-dependency-links/src/zc/buildout/easy_install.txt 2007-10-20 19:22:14 UTC (rev 80951)
@@ -83,7 +83,7 @@
when selecting distributions. This can be used to specify a set of
distribution versions independent of other requirements.
-use_depenency_links
+use_dependency_links
A flag indicating whether to search for dependencies using the
setup dependency_links metadata or not. If true, links are searched
for using dependency_links in preference to other
@@ -337,20 +337,24 @@
>>> [d.version for d in ws]
['0.3', '1.1']
-Depenency links
----------------
+Dependency links
+----------------
-Setuptools allows metadata that descibes where to search for package
+Setuptools allows metadata that describes where to search for package
dependencies. This option is called dependency_links. Buildout has its
own notion of where to look for dependencies, but it also uses the
setup tools dependency_links information if it's available.
-Let's demo this by creating an egg that specifies dependency_links. To
-begin, let's create a new egg repository. This repository uses the
-same sample eggs as the normal testing repository.
+Let's demo this by creating an egg that specifies dependency_links.
- >>> link_server2 = start_server(sample_eggs)
+To begin, let's create a new egg repository. This repository hold a
+newer version of the 'demoneeded' egg than the sample repository does.
+ >>> repoloc = tmpdir('repo')
+ >>> from zc.buildout.tests import create_egg
+ >>> create_egg('demoneeded', '1.2', repoloc)
+ >>> link_server2 = start_server(repoloc)
+
Turn on logging on this server so that we can see when eggs are pulled
from it.
@@ -361,8 +365,7 @@
Now we can create an egg that specifies that its dependencies are
found on this server.
- >>> from zc.buildout.tests import create_egg
- >>> repoloc = tmpdir('repo')
+ >>> repoloc = tmpdir('repo2')
>>> create_egg('hasdeps', '1.0', repoloc,
... install_requires = "'demoneeded'",
... dependency_links = [link_server2])
@@ -378,7 +381,7 @@
... ['hasdeps'], example_dest,
... links=[link_server3], index=link_server3+'index/')
GET 200 /
- GET 200 /demoneeded-1.1.zip
+ GET 200 /demoneeded-1.2-pyN.N.egg
The server logs show that the dependency was retrieved from the server
specified in the dependency_links.
@@ -389,22 +392,24 @@
>>> rmdir(example_dest)
>>> example_dest = tmpdir('example-install')
>>> workingset = zc.buildout.easy_install.install(
- ... ['hasdeps'], example_dest, index=link_server3+'index/',
- ... links=[link_server, link_server3]) #doctest: +ELLIPSIS
- GET 200 /...
+ ... ['hasdeps'], example_dest, index=link_server+'index/',
+ ... links=[link_server, link_server3])
+ GET 200 /
+ GET 200 /demoneeded-1.2-pyN.N.egg
-
Once again the dependency is fetched from the logging server even
-though it is also available from the non-logging server.
+though it is also available from the non-logging server. This is
+because the version on the logging server is newer and buildout
+normally chooses the newest egg available.
If you wish to control where dependencies come from regardless of
dependency_links setup metadata use the 'use_dependency_links' option
-to zc.buildout.easy_install.install.
+to zc.buildout.easy_install.install().
>>> rmdir(example_dest)
>>> example_dest = tmpdir('example-install')
>>> workingset = zc.buildout.easy_install.install(
- ... ['hasdeps'], example_dest, index=link_server3+'index/',
+ ... ['hasdeps'], example_dest, index=link_server+'index/',
... links=[link_server, link_server3],
... use_dependency_links=False)
@@ -412,6 +417,45 @@
logging server. When you specify not to use dependency_links, eggs
will only be searched for using the links you explicitly provide.
+Another way to control this option is with the
+zc.buildout.easy_install.use_dependency_links() function. This
+function sets the default behavior for the zc.buildout.easy_install()
+function.
+
+ >>> zc.buildout.easy_install.use_dependency_links(False)
+ True
+
+The function returns its previous setting.
+
+ >>> rmdir(example_dest)
+ >>> example_dest = tmpdir('example-install')
+ >>> workingset = zc.buildout.easy_install.install(
+ ... ['hasdeps'], example_dest, index=link_server+'index/',
+ ... links=[link_server, link_server3])
+
+It can be overridden by passing a keyword argument to the install
+function.
+
+ >>> rmdir(example_dest)
+ >>> example_dest = tmpdir('example-install')
+ >>> workingset = zc.buildout.easy_install.install(
+ ... ['hasdeps'], example_dest, index=link_server+'index/',
+ ... links=[link_server, link_server3],
+ ... use_dependency_links=True)
+ GET 200 /demoneeded-1.2-pyN.N.egg
+
+To return the dependency_links behavior to normal call the function again.
+
+ >>> zc.buildout.easy_install.use_dependency_links(True)
+ False
+ >>> rmdir(example_dest)
+ >>> example_dest = tmpdir('example-install')
+ >>> workingset = zc.buildout.easy_install.install(
+ ... ['hasdeps'], example_dest, index=link_server+'index/',
+ ... links=[link_server, link_server3])
+ GET 200 /demoneeded-1.2-pyN.N.egg
+
+
Script generation
-----------------
More information about the Checkins
mailing list