Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
S
slapos.buildout
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Jérome Perrin
slapos.buildout
Commits
a18b558c
Commit
a18b558c
authored
Apr 28, 2012
by
Jim Fulton
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Removed setuptools support :(
parent
172fd4df
Changes
20
Expand all
Hide whitespace changes
Inline
Side-by-side
Showing
20 changed files
with
213 additions
and
450 deletions
+213
-450
README.rst
README.rst
+43
-185
bootstrap/bootstrap.py
bootstrap/bootstrap.py
+3
-17
dev.py
dev.py
+3
-2
src/zc/buildout/bootstrap.txt
src/zc/buildout/bootstrap.txt
+4
-76
src/zc/buildout/buildout.py
src/zc/buildout/buildout.py
+11
-11
src/zc/buildout/buildout.txt
src/zc/buildout/buildout.txt
+11
-11
src/zc/buildout/easy_install.py
src/zc/buildout/easy_install.py
+20
-20
src/zc/buildout/easy_install.txt
src/zc/buildout/easy_install.txt
+13
-13
src/zc/buildout/repeatable.txt
src/zc/buildout/repeatable.txt
+7
-7
src/zc/buildout/runsetup.txt
src/zc/buildout/runsetup.txt
+3
-3
src/zc/buildout/setup.txt
src/zc/buildout/setup.txt
+1
-1
src/zc/buildout/testing.py
src/zc/buildout/testing.py
+3
-3
src/zc/buildout/tests.py
src/zc/buildout/tests.py
+42
-41
src/zc/buildout/unzip.txt
src/zc/buildout/unzip.txt
+3
-3
src/zc/buildout/update.txt
src/zc/buildout/update.txt
+22
-33
src/zc/buildout/upgrading_distribute.txt
src/zc/buildout/upgrading_distribute.txt
+13
-13
zc.recipe.egg_/src/zc/recipe/egg/README.txt
zc.recipe.egg_/src/zc/recipe/egg/README.txt
+6
-6
zc.recipe.egg_/src/zc/recipe/egg/api.txt
zc.recipe.egg_/src/zc/recipe/egg/api.txt
+1
-1
zc.recipe.egg_/src/zc/recipe/egg/egg.py
zc.recipe.egg_/src/zc/recipe/egg/egg.py
+2
-2
zc.recipe.egg_/src/zc/recipe/egg/tests.py
zc.recipe.egg_/src/zc/recipe/egg/tests.py
+2
-2
No files found.
README.rst
View file @
a18b558c
...
...
@@ -2,188 +2,46 @@
Buildout
********
*Note*: the 1.4.4 release is a release for people who encounter trouble
with the 1.5 line. By switching to `the associated bootstrap script
<https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py>`_
you can stay on 1.4.4 until you are ready to migrate.
.. contents::
The Buildout project provides support for creating applications,
especially Python applications. It provides tools for assembling
applications from multiple parts, Python or otherwise. An application
may actually contain multiple programs, processes, and configuration
settings.
The word "buildout" refers to a description of a set of parts and the
software to create and assemble them. It is often used informally to
refer to an installed system based on a buildout definition. For
example, if we are creating an application named "Foo", then "the Foo
buildout" is the collection of configuration and application-specific
software that allows an instance of the application to be created. We
may refer to such an instance of the application informally as "a Foo
buildout".
To get a feel for some of the things you might use buildouts for, see
the `Buildout examples`_.
To lean more about using buildouts, see `Detailed Documentation`_.
To see screencasts, talks, useful links and more documentation, visit
the `Buildout website <http://www.buildout.org>`_.
Recipes
*******
Existing recipes include:
`zc.recipe.egg <http://pypi.python.org/pypi/zc.recipe.egg>`_
The egg recipe installes one or more eggs, with their
dependencies. It installs their console-script entry points with
the needed eggs included in their paths.
For an extensive list of recipes, look at the `Framework Buildout category
<http://pypi.python.org/pypi?:action=browse&c=512>`_ on the Python Package
Index.
Buildout examples
*****************
Here are a few examples of what you can do with buildouts. We'll
present these as a set of use cases.
Try out an egg
==============
Sometimes you want to try an egg (or eggs) that someone has released.
You'd like to get a Python interpreter that lets you try things
interactively or run sample scripts without having to do path
manipulations. If you can and don't mind modifying your Python
installation, you could use easy_install, otherwise, you could create
a directory somewhere and create a buildout.cfg file in that directory
containing::
[buildout]
parts = mypython
[mypython]
recipe = zc.recipe.egg
interpreter = mypython
eggs = theegg
where theegg is the name of the egg you want to try out.
Run buildout in this directory. It will create a bin subdirectory
that includes a mypython script. If you run mypython without any
arguments you'll get an interactive interpreter with the egg in the
path. If you run it with a script and script arguments, the script
will run with the egg in its path. Of course, you can specify as many
eggs as you want in the eggs option.
If the egg provides any scripts (console_scripts entry points), those
will be installed in your bin directory too.
Work on a package
=================
I often work on packages that are managed separately. They don't have
scripts to be installed, but I want to be able to run their tests
using the `zope.testing test runner
<http://www.python.org/pypi/zope.testing>`_. In this kind of
application, the program to be installed is the test runner. A good
example of this is `zc.ngi <http://svn.zope.org/zc.ngi/trunk/>`_.
Here I have a subversion project for the zc.ngi package. The software
is in the src directory. The configuration file is very simple::
[buildout]
develop = .
parts = test
[test]
recipe = zc.recipe.testrunner
eggs = zc.ngi
I use the develop option to create a develop egg based on the current
directory. I request a test script named "test" using the
zc.recipe.testrunner recipe. In the section for the test script, I
specify that I want to run the tests in the zc.ngi package.
When I check out this project into a new sandbox, I run bootstrap.py
to get setuptools and buildout and to create bin/buildout. I run
bin/buildout, which installs the test script, bin/test, which I can
then use to run the tests.
This is probably the most common type of buildout.
If I need to run a previous version of buildout, I use the
`--version` option of the bootstrap.py script::
$ python bootstrap.py --version 1.4.2
The `buildout project <https://github.com/buildout/buildout>`_
is a slightly more complex example of this type of buildout.
Install egg-based scripts
=========================
A variation of the `Try out an egg`_ use case is to install scripts
into your ~/bin directory (on Unix, of course). My ~/bin directory is
a buildout with a configuration file that looks like::
[buildout]
parts = foo bar
bin-directory = .
[foo]
...
where foo and bar are packages with scripts that I want available. As
I need new scripts, I can add additional sections. The bin-directory
option specified that scripts should be installed into the current
directory.
Multi-program multi-machine systems
===================================
Using an older prototype version of the buildout, we've build a number
of systems involving multiple programs, databases, and machines. One
typical example consists of:
- Multiple Zope instances
- Multiple ZEO servers
- An LDAP server
- Cache-invalidation and Mail delivery servers
- Dozens of add-on packages
- Multiple test runners
- Multiple deployment modes, including dev, stage, and prod,
with prod deployment over multiple servers
Parts installed include:
- Application software installs, including Zope, ZEO and LDAP
software
- Add-on packages
- Bundles of configuration that define Zope, ZEO and LDAP instances
- Utility scripts such as test runners, server-control
scripts, cron jobs.
Questions and Bug Reporting
***************************
Please send questions and comments to the
`distutils SIG mailing list <mailto://distutils-sig@python.org>`_.
Report bugs using the `buildout Issues Tracker
<https://github.com/buildout/buildout/issues>`_.
Buildout is a project designed to solve 2 problems:
1. Application-centric assembly and deployment
*Assembly* runs the gamut from stitching together libraries to
create a running program, to production deployment configuration of
applications, and associated systems and tools (e.g. run-control
scripts, cron jobs, logs, service registration, etc.).
Buildout might be confused with build tools like make or ant, but
it is a little higher level and might invoke systems like make or
ant to get it's work done.
Buildout might be confused with systems like puppet or chef, but it
is more application focused. Systems like puppet or chef might
use buildout to get their work done.
Buildout is also somewhat Python-centric, even though it can be
used to assemble and deploy non-python applications. It has some
special features for assembling Python programs. It's scripted with
Python, unlike, say puppet or chef, which are scripted with Ruby.
2. Repeatable assembly of programs from Python software distributions
Buildout puts great effort toward making program assembly a highly
repeatable process, whether in a very open-ended development mode,
where dependency versions aren't locked down, or in a deployment
environment where dependency versions are fully specified. You
should be able to check buildout into a VCS and later check it out.
Two checkouts built at the same time in the same environment should
always give the same result, regardless of their history. Among
other things, after a buildout, all dependencies should be at the
most recent version consistent with any version specifications
expressed in the buildout.
Buildout supports applications consisting of multiple programs,
with different programs in an application free to use different
versions of Python distributions. This is in contrast with a
Python installation (real or virtual), where, for any given
distribution, there can only be one installed.
To learn more about buildout, including how to use it, see the
``Buildout Documentation <http://packages.python.org/buildout/>``_.
bootstrap/bootstrap.py
View file @
a18b558c
...
...
@@ -34,10 +34,6 @@ parser.add_option("-v", "--version", dest="version", default='1.4.4',
help
=
'Use a specific zc.buildout version. *This '
'bootstrap script defaults to '
'1.4.4, unlike usual buildpout bootstrap scripts.*'
)
parser
.
add_option
(
"-d"
,
"--distribute"
,
action
=
"store_true"
,
dest
=
"distribute"
,
default
=
False
,
help
=
"Use Disribute rather than Setuptools."
)
parser
.
add_option
(
"-c"
,
None
,
action
=
"store"
,
dest
=
"config_file"
,
help
=
(
"Specify the path to the buildout configuration "
"file to be used."
))
...
...
@@ -53,7 +49,6 @@ if options.version is not None:
else
:
VERSION
=
''
USE_DISTRIBUTE
=
options
.
distribute
args
=
args
+
[
'bootstrap'
]
to_reload
=
False
...
...
@@ -64,14 +59,9 @@ try:
raise
ImportError
except
ImportError
:
ez
=
{}
if
USE_DISTRIBUTE
:
exec
urllib2
.
urlopen
(
'http://python-distribute.org/distribute_setup.py'
exec
urllib2
.
urlopen
(
'http://python-distribute.org/distribute_setup.py'
).
read
()
in
ez
ez
[
'use_setuptools'
](
to_dir
=
tmpeggs
,
download_delay
=
0
,
no_fake
=
True
)
else
:
exec
urllib2
.
urlopen
(
'http://peak.telecommunity.com/dist/ez_setup.py'
).
read
()
in
ez
ez
[
'use_setuptools'
](
to_dir
=
tmpeggs
,
download_delay
=
0
)
ez
[
'use_setuptools'
](
to_dir
=
tmpeggs
,
download_delay
=
0
,
no_fake
=
True
)
if
to_reload
:
reload
(
pkg_resources
)
...
...
@@ -80,10 +70,7 @@ except ImportError:
ws
=
pkg_resources
.
working_set
if
USE_DISTRIBUTE
:
requirement
=
'distribute'
else
:
requirement
=
'setuptools'
requirement
=
'distribute'
env
=
dict
(
os
.
environ
,
PYTHONPATH
=
...
...
@@ -99,7 +86,6 @@ if 'bootstrap-testing-find-links' in os.environ:
cmd
.
append
(
'zc.buildout'
+
VERSION
)
import
subprocess
if
subprocess
.
call
(
cmd
,
env
=
env
)
!=
0
:
raise
Exception
(
...
...
dev.py
View file @
a18b558c
...
...
@@ -34,8 +34,9 @@ try:
import
pkg_resources
except
ImportError
:
ez
=
{}
exec
urllib2
.
urlopen
(
'http://peak.telecommunity.com/dist/ez_setup.py'
).
read
()
in
ez
exec
urllib2
.
urlopen
(
'http://python-distribute.org/distribute_setup.py'
).
read
()
in
ez
ez
[
'use_setuptools'
](
to_dir
=
'eggs'
,
download_delay
=
0
)
import
pkg_resources
...
...
src/zc/buildout/bootstrap.txt
View file @
a18b558c
...
...
@@ -57,6 +57,7 @@ Let's try with an unknown version::
... 'bootstrap.py --version UNKNOWN'); print 'X' # doctest: +ELLIPSIS
...
X
...
No local packages or download links found for zc.buildout==UNKNOWN
...
...
...
@@ -65,8 +66,9 @@ Now let's try with `1.1.2`, which happens to exist::
>>> print 'X'; print system(
... zc.buildout.easy_install._safe_arg(sys.executable)+' '+
... 'bootstrap.py --version 1.1.2'); print 'X'
...
...
# doctest: +ELLIPSIS
X
...
Generated script '/sample/bin/buildout'.
<BLANKLINE>
X
...
...
@@ -81,7 +83,7 @@ Let's make sure the generated `buildout` script uses it::
<BLANKLINE>
import sys
sys.path[0:0] = [
'/sample/eggs/
setuptools
-...egg',
'/sample/eggs/
distribute
-...egg',
'/sample/eggs/zc.buildout-1.1.2...egg',
]
<BLANKLINE>
...
...
@@ -98,35 +100,6 @@ Let's try with `1.2.1`::
... 'bootstrap.py --version 1.2.1'); print 'X' # doctest: +ELLIPSIS
...
X
Generated script '/sample/bin/buildout'.
<BLANKLINE>
X
Let's make sure the generated `buildout` script uses it::
>>> print open(buildout_script).read() # doctest: +ELLIPSIS
#...
<BLANKLINE>
import sys
sys.path[0:0] = [
'/sample/eggs/setuptools-...egg',
'/sample/eggs/zc.buildout-1.2.1...egg',
]
<BLANKLINE>
import zc.buildout.buildout
<BLANKLINE>
if __name__ == '__main__':
zc.buildout.buildout.main()
<BLANKLINE>
`zc.buildout` now can also run with `Distribute` with the `--distribute` option::
>>> print 'X'; print system(
... zc.buildout.easy_install._safe_arg(sys.executable)+' '+
... 'bootstrap.py --distribute'); print 'X' # doctest: +ELLIPSIS
...
X
...
Generated script '/sample/bin/buildout'.
<BLANKLINE>
...
...
@@ -134,35 +107,6 @@ Let's make sure the generated `buildout` script uses it::
Let's make sure the generated `buildout` script uses it::
>>> print open(buildout_script).read() # doctest: +ELLIPSIS
#...
<BLANKLINE>
import sys
sys.path[0:0] = [
'/sample/eggs/distribute-...egg',
'/sample/eggs/zc.buildout-...egg',
]
<BLANKLINE>
import zc.buildout.buildout
<BLANKLINE>
if __name__ == '__main__':
zc.buildout.buildout.main()
<BLANKLINE>
Make sure both options can be used together::
>>> print 'X'; print system(
... zc.buildout.easy_install._safe_arg(sys.executable)+' '+
... 'bootstrap.py --distribute --version 1.2.1'); print 'X' # doctest: +ELLIPSIS
...
X
...
Generated script '/sample/bin/buildout'.
<BLANKLINE>
X
Let's make sure the generated `buildout` script uses ``Distribute`` *and* ``zc.buildout-1.2.1``::
>>> print open(buildout_script).read() # doctest: +ELLIPSIS
#...
<BLANKLINE>
...
...
@@ -178,20 +122,4 @@ Let's make sure the generated `buildout` script uses ``Distribute`` *and* ``zc.b
zc.buildout.buildout.main()
<BLANKLINE>
Last, the -c option needs to work on bootstrap.py::
>>> conf_file = os.path.join(sample_buildout, 'other.cfg')
>>> f = open(conf_file, 'w')
>>> f.write('[buildout]\nparts=\n\n')
>>> f.close()
>>> print 'X'; print system(
... zc.buildout.easy_install._safe_arg(sys.executable)+' '+
... 'bootstrap.py -c %s --distribute' % conf_file); print 'X' # doctest: +ELLIPSIS
...
X
...
Generated script '/sample/bin/buildout'.
<BLANKLINE>
X
src/zc/buildout/buildout.py
View file @
a18b558c
...
...
@@ -43,7 +43,7 @@ import zc.buildout.easy_install
realpath
=
zc
.
buildout
.
easy_install
.
realpath
pkg_resources_loc
=
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'
setuptools
'
)).
location
pkg_resources
.
Requirement
.
parse
(
'
distribute
'
)).
location
_isurl
=
re
.
compile
(
'([a-zA-Z0-9+.-]+)://'
).
match
...
...
@@ -355,9 +355,9 @@ class Buildout(UserDict.DictMixin):
self
.
_setup_directories
()
# Now copy buildout and
setuptools
eggs, and record destination eggs:
# Now copy buildout and
distribute
eggs, and record destination eggs:
entries
=
[]
for
name
in
'
setuptools
'
,
'zc.buildout'
:
for
name
in
'
distribute
'
,
'zc.buildout'
:
r
=
pkg_resources
.
Requirement
.
parse
(
name
)
dist
=
pkg_resources
.
working_set
.
find
(
r
)
if
dist
.
precedence
==
pkg_resources
.
DEVELOP_DIST
:
...
...
@@ -802,7 +802,7 @@ class Buildout(UserDict.DictMixin):
self
.
_log_level
=
level
def
_maybe_upgrade
(
self
):
# See if buildout or
setuptools
need to be upgraded.
# See if buildout or
distribute
need to be upgraded.
# If they do, do the upgrade and restart the buildout process.
__doing__
=
'Checking for upgrades.'
...
...
@@ -812,7 +812,7 @@ class Buildout(UserDict.DictMixin):
ws
=
zc
.
buildout
.
easy_install
.
install
(
[
(
spec
+
' '
+
self
[
'buildout'
].
get
(
spec
+
'-version'
,
''
)).
strip
()
for
spec
in
(
'zc.buildout'
,
'
setuptools
'
)
for
spec
in
(
'zc.buildout'
,
'
distribute
'
)
],
self
[
'buildout'
][
'eggs-directory'
],
links
=
self
[
'buildout'
].
get
(
'find-links'
,
''
).
split
(),
...
...
@@ -822,7 +822,7 @@ class Buildout(UserDict.DictMixin):
)
upgraded
=
[]
for
project
in
'zc.buildout'
,
'
setuptools
'
:
for
project
in
'zc.buildout'
,
'
distribute
'
:
req
=
pkg_resources
.
Requirement
.
parse
(
project
)
project_location
=
pkg_resources
.
working_set
.
find
(
req
).
location
if
ws
.
find
(
req
).
location
!=
project_location
:
...
...
@@ -930,7 +930,7 @@ class Buildout(UserDict.DictMixin):
fd
,
tsetup
=
tempfile
.
mkstemp
()
try
:
os
.
write
(
fd
,
zc
.
buildout
.
easy_install
.
runsetup_template
%
dict
(
setuptools
=
pkg_resources_loc
,
distribute
=
pkg_resources_loc
,
setupdir
=
os
.
path
.
dirname
(
setup
),
setup
=
setup
,
__file__
=
setup
,
...
...
@@ -1537,7 +1537,7 @@ Commands:
bootstrap
Create a new buildout in the current working directory, copying
the buildout and
setuptools
eggs and, creating a basic directory
the buildout and
distribute
eggs and, creating a basic directory
structure and a buildout-local buildout script.
init
...
...
@@ -1548,10 +1548,10 @@ Commands:
setup script [setup command and options]
Run a given setup script arranging that
setuptools
is in the
Run a given setup script arranging that
distribute
is in the
script's path and and that it has been imported so that
setuptools
-provided commands (like bdist_egg) can be used even if
the setup script doesn't import setuptools
itself
.
distribute
-provided commands (like bdist_egg) can be used even if
the setup script doesn't import setuptools.
The script can be given either as a script path or a path to a
directory containing a setup.py script.
...
...
src/zc/buildout/buildout.txt
View file @
a18b558c
...
...
@@ -18,7 +18,7 @@ buildout software and create a buildout instance:
script installed in a Python scripts area.
2. Use the buildout bootstrap script to create a buildout that
includes both the
setuptools
and zc.buildout eggs. This allows you
includes both the
distribute
and zc.buildout eggs. This allows you
to use the buildout software without modifying a Python install.
The buildout script is installed into your buildout local scripts
area.
...
...
@@ -32,7 +32,7 @@ such as a subversion repository, that includes some software source
directories, buildout configuration files, and a copy of the buildout
bootstrap script. To work on the project, one would check out the
project from the repository and run the bootstrap script which
installs
setuptools
and zc.buildout into the checkout as well as any
installs
distribute
and zc.buildout into the checkout as well as any
parts defined.
We have a sample buildout that we created using the bootstrap command
...
...
@@ -53,7 +53,7 @@ The bin directory contains scripts.
- buildout
>>> ls(sample_buildout, 'eggs')
-
setuptools
-0.6-py2.4.egg
-
distribute
-0.6-py2.4.egg
- zc.buildout-1.0-py2.4.egg
The develop-eggs and parts directories are initially empty:
...
...
@@ -228,7 +228,7 @@ classes must be exposed as entry points in the zc.buildout group. we
give entry points names within the group.
We also need a README.txt for our recipes to avoid an annoying warning
from distutils, on which
setuptools
and zc.buildout are based:
from distutils, on which
distribute
and zc.buildout are based:
>>> write(sample_buildout, 'recipes', 'README.txt', " ")
...
...
@@ -2194,10 +2194,10 @@ database is shown.
... """)
>>> print system(buildout+' -vv'), # doctest: +NORMALIZE_WHITESPACE
Installing 'zc.buildout', '
setuptools
'.
Installing 'zc.buildout', '
distribute
'.
We have a develop egg: zc.buildout 1.0.0.
We have the best distribution that satisfies '
setuptools
'.
Picked:
setuptools
= 0.6
We have the best distribution that satisfies '
distribute
'.
Picked:
distribute
= 0.6
<BLANKLINE>
Configuration data:
[buildout]
...
...
@@ -2267,7 +2267,7 @@ Creating new buildouts and bootstrapping
----------------------------------------
If zc.buildout is installed, you can use it to create a new buildout
with it's own local copies of zc.buildout and
setuptools
and with
with it's own local copies of zc.buildout and
distribute
and with
local buildout scripts.
>>> sample_bootstrapped = tmpdir('sample-bootstrapped')
...
...
@@ -2296,13 +2296,13 @@ Note that a basic setup.cfg was created for us.
>>> _ = (ls(sample_bootstrapped, 'eggs'),
... ls(sample_bootstrapped, 'develop-eggs'))
-
setuptools
-0.6-py2.3.egg
-
distribute
-0.6-py2.3.egg
- zc.buildout-1.0-py2.3.egg
(We list both the eggs and develop-eggs directories because the
buildout or
setuptools
egg could be installed in the develop-eggs
buildout or
distribute
egg could be installed in the develop-eggs
directory if the original buildout had develop eggs for either
buildout or
setuptools
.)
buildout or
distribute
.)
Note that the buildout script was installed but not run. To run
the buildout, we'd have to run the installed buildout script.
...
...
src/zc/buildout/easy_install.py
View file @
a18b558c
...
...
@@ -14,7 +14,7 @@
"""Python easy_install API
This module provides a high-level Python API for installing packages.
It doesn't install scripts. It uses
setuptools
and requires it to be
It doesn't install scripts. It uses
distribute
and requires it to be
installed.
"""
...
...
@@ -56,13 +56,13 @@ if is_jython:
jython_os_name
=
(
java
.
lang
.
System
.
getProperties
()[
'os.name'
]).
lower
()
setuptools
_loc
=
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'
setuptools
'
)
distribute
_loc
=
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'
distribute
'
)
).
location
# Include buildout and
setuptools
eggs in paths
buildout_and_
setuptools
_path
=
[
setuptools
_loc
,
# Include buildout and
distribute
eggs in paths
buildout_and_
distribute
_path
=
[
distribute
_loc
,
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'zc.buildout'
)).
location
,
]
...
...
@@ -162,7 +162,7 @@ class Installer:
self
.
_index_url
=
index
if
always_unzip
is
not
None
:
self
.
_always_unzip
=
always_unzip
path
=
(
path
and
path
[:]
or
[])
+
buildout_and_
setuptools
_path
path
=
(
path
and
path
[:]
or
[])
+
buildout_and_
distribute
_path
if
dest
is
not
None
and
dest
not
in
path
:
path
.
insert
(
0
,
dest
)
self
.
_path
=
path
...
...
@@ -273,7 +273,7 @@ class Installer:
tmp
=
tempfile
.
mkdtemp
(
dir
=
dest
)
try
:
path
=
setuptools
_loc
path
=
distribute
_loc
args
=
[
sys
.
executable
,
'-c'
,
_easy_install_cmd
,
'-mUNxd'
,
tmp
]
if
self
.
_always_unzip
:
...
...
@@ -417,7 +417,7 @@ class Installer:
and
(
realpath
(
new_location
)
==
realpath
(
dist
.
location
))
and
os
.
path
.
isfile
(
new_location
)
):
#
setuptools
avoids making extra copies, but we want to copy
#
distribute
avoids making extra copies, but we want to copy
# to the download cache
shutil
.
copy2
(
new_location
,
tmp
)
new_location
=
os
.
path
.
join
(
tmp
,
os
.
path
.
basename
(
new_location
))
...
...
@@ -542,21 +542,21 @@ class Installer:
return
dists
def
_maybe_add_
setuptools
(
self
,
ws
,
dist
):
def
_maybe_add_
distribute
(
self
,
ws
,
dist
):
if
dist
.
has_metadata
(
'namespace_packages.txt'
):
for
r
in
dist
.
requires
():
if
r
.
project_name
==
'setuptools'
:
if
r
.
project_name
in
(
'setuptools'
,
'distribute'
)
:
break
else
:
# We have a namespace package but no requirement for
setuptools
# We have a namespace package but no requirement for
distribute
if
dist
.
precedence
==
pkg_resources
.
DEVELOP_DIST
:
logger
.
warn
(
"Develop distribution: %s
\
n
"
"uses namespace packages but the distribution "
"does not require
setuptools
."
,
"does not require
distribute
."
,
dist
)
requirement
=
self
.
_constrain
(
pkg_resources
.
Requirement
.
parse
(
'
setuptools
'
)
pkg_resources
.
Requirement
.
parse
(
'
distribute
'
)
)
if
ws
.
find
(
requirement
)
is
None
:
for
dist
in
self
.
_get_dist
(
requirement
,
ws
,
False
):
...
...
@@ -600,7 +600,7 @@ class Installer:
for
requirement
in
requirements
:
for
dist
in
self
.
_get_dist
(
requirement
,
ws
,
self
.
_always_unzip
):
ws
.
add
(
dist
)
self
.
_maybe_add_
setuptools
(
ws
,
dist
)
self
.
_maybe_add_
distribute
(
ws
,
dist
)
# OK, we have the requested distributions and they're in the working
# set, but they may have unmet requirements. We'll simply keep
...
...
@@ -626,7 +626,7 @@ class Installer:
):
ws
.
add
(
dist
)
self
.
_maybe_add_
setuptools
(
ws
,
dist
)
self
.
_maybe_add_
distribute
(
ws
,
dist
)
except
pkg_resources
.
VersionConflict
,
err
:
raise
VersionConflict
(
err
,
ws
)
else
:
...
...
@@ -823,7 +823,7 @@ def develop(setup, dest,
undo
.
append
(
lambda
:
os
.
close
(
fd
))
os
.
write
(
fd
,
runsetup_template
%
dict
(
setuptools
=
setuptools
_loc
,
distribute
=
distribute
_loc
,
setupdir
=
directory
,
setup
=
setup
,
__file__
=
setup
,
...
...
@@ -1006,7 +1006,7 @@ def _script(module_name, attrs, path, dest, arguments, initialization, rsetup):
if
is_win32
:
# generate exe file and give the script a magic name:
exe
=
script
+
'.exe'
new_data
=
pkg_resources
.
resource_string
(
'
setuptools
'
,
'cli.exe'
)
new_data
=
pkg_resources
.
resource_string
(
'
distribute
'
,
'cli.exe'
)
if
not
os
.
path
.
exists
(
exe
)
or
(
open
(
exe
,
'rb'
).
read
()
!=
new_data
):
# Only write it if it's different.
open
(
exe
,
'wb'
).
write
(
new_data
)
...
...
@@ -1062,7 +1062,7 @@ def _pyscript(path, dest, rsetup):
# generate exe file and give the script a magic name:
exe
=
script
+
'.exe'
open
(
exe
,
'wb'
).
write
(
pkg_resources
.
resource_string
(
'
setuptools
'
,
'cli.exe'
)
pkg_resources
.
resource_string
(
'
distribute
'
,
'cli.exe'
)
)
generated
.
append
(
exe
)
...
...
@@ -1115,7 +1115,7 @@ if _interactive:
runsetup_template
=
"""
import sys
sys.path.insert(0, %(setupdir)r)
sys.path.insert(0, %(
setuptools
)r)
sys.path.insert(0, %(
distribute
)r)
import os, setuptools
__file__ = %(__file__)r
...
...
src/zc/buildout/easy_install.txt
View file @
a18b558c
...
...
@@ -136,7 +136,7 @@ And the actual eggs were added to the eggs directory.
>>> ls(dest)
- demo-0.2-py2.4.egg
-
demoneeded-1.1-py2.4.egg
d
demoneeded-1.1-py2.4.egg
If we remove the version restriction on demo, but specify a false
value for newest, no new distributions will be installed:
...
...
@@ -146,7 +146,7 @@ value for newest, no new distributions will be installed:
... newest=False)
>>> ls(dest)
- demo-0.2-py2.4.egg
-
demoneeded-1.1-py2.4.egg
d
demoneeded-1.1-py2.4.egg
If we leave off the newest option, we'll get an update for demo:
...
...
@@ -155,7 +155,7 @@ If we leave off the newest option, we'll get an update for demo:
>>> ls(dest)
- demo-0.2-py2.4.egg
- demo-0.3-py2.4.egg
-
demoneeded-1.1-py2.4.egg
d
demoneeded-1.1-py2.4.egg
Note that we didn't get the newest versions available. There were
release candidates for newer versions of both packages. By default,
...
...
@@ -178,8 +178,8 @@ The old setting is returned.
- demo-0.2-py2.4.egg
- demo-0.3-py2.4.egg
- demo-0.4c1-py2.4.egg
-
demoneeded-1.1-py2.4.egg
-
demoneeded-1.2c1-py2.4.egg
d
demoneeded-1.1-py2.4.egg
d
demoneeded-1.2c1-py2.4.egg
Let's put the setting back to the default.
...
...
@@ -204,9 +204,9 @@ dependencies. We might do this to specify a specific version.
- demo-0.2-py2.4.egg
- demo-0.3-py2.4.egg
- demo-0.4c1-py2.4.egg
-
demoneeded-1.0-py2.4.egg
-
demoneeded-1.1-py2.4.egg
-
demoneeded-1.2c1-py2.4.egg
d
demoneeded-1.0-py2.4.egg
d
demoneeded-1.1-py2.4.egg
d
demoneeded-1.2c1-py2.4.egg
d other-1.0-py2.4.egg
We can request that eggs be unzipped even if they are zip safe. This
...
...
@@ -230,7 +230,7 @@ can be useful when debugging.
>>> ls(dest)
- demo-0.3-py2.4.egg
-
demoneeded-1.1-py2.4.egg
d
demoneeded-1.1-py2.4.egg
We can also set a default by calling the always_unzip function:
...
...
@@ -259,7 +259,7 @@ The old default is returned:
>>> ls(dest)
- demo-0.3-py2.4.egg
-
demoneeded-1.1-py2.4.egg
d
demoneeded-1.1-py2.4.egg
>>> rmdir(dest)
>>> dest = tmpdir('sample-install')
...
...
@@ -1009,7 +1009,7 @@ Now if we look in our destination directory, we see we have an extdemo egg:
>>> ls(dest)
- demo-0.2-py2.4.egg
d demo-0.3-py2.4.egg
-
demoneeded-1.0-py2.4.egg
d
demoneeded-1.0-py2.4.egg
d demoneeded-1.1-py2.4.egg
d extdemo-1.4-py2.4-unix-i686.egg
...
...
@@ -1050,7 +1050,7 @@ If we run build with newest set to False, we won't get an update:
>>> ls(dest)
- demo-0.2-py2.4.egg
d demo-0.3-py2.4.egg
-
demoneeded-1.0-py2.4.egg
d
demoneeded-1.0-py2.4.egg
d demoneeded-1.1-py2.4.egg
d extdemo-1.4-py2.4-unix-i686.egg
...
...
@@ -1066,7 +1066,7 @@ get an updated egg:
>>> ls(dest)
- demo-0.2-py2.4.egg
d demo-0.3-py2.4.egg
-
demoneeded-1.0-py2.4.egg
d
demoneeded-1.0-py2.4.egg
d demoneeded-1.1-py2.4.egg
d extdemo-1.4-py2.4-unix-i686.egg
d extdemo-1.5-py2.4-unix-i686.egg
...
...
src/zc/buildout/repeatable.txt
View file @
a18b558c
...
...
@@ -124,10 +124,10 @@ about versions used. If we run the buildout in verbose mode without
specifying a versions section:
>>> print system(buildout+' buildout:versions= -v'), # doctest: +ELLIPSIS
Installing 'zc.buildout', '
setuptools
'.
Installing 'zc.buildout', '
distribute
'.
We have a develop egg: zc.buildout 1.0.0.
We have the best distribution that satisfies '
setuptools
'.
Picked:
setuptools
= 0.6
We have the best distribution that satisfies '
distribute
'.
Picked:
distribute
= 0.6
Installing 'spam'.
We have the best distribution that satisfies 'spam'.
Picked: spam = 2.
...
...
@@ -146,10 +146,10 @@ that we can fix them in a versions section.
If we run the buildout with the versions section:
>>> print system(buildout+' -v'), # doctest: +ELLIPSIS
Installing 'zc.buildout', '
setuptools
'.
Installing 'zc.buildout', '
distribute
'.
We have a develop egg: zc.buildout 1.0.0.
We have the best distribution that satisfies '
setuptools
'.
Picked:
setuptools
= 0.6
We have the best distribution that satisfies '
distribute
'.
Picked:
distribute
= 0.6
Installing 'spam'.
We have the distribution that satisfies 'spam==1'.
Uninstalling foo.
...
...
@@ -157,7 +157,7 @@ If we run the buildout with the versions section:
recipe v1
We won't get output for the spam distribution, which we didn't pick,
but we will get output for
setuptools
, which we didn't specify
but we will get output for
distribute
, which we didn't specify
versions for.
You can request buildout to generate an error if it picks any
...
...
src/zc/buildout/runsetup.txt
View file @
a18b558c
...
...
@@ -5,12 +5,12 @@ Buildouts are often used to work on packages that will be distributed
as eggs. During development, we use develop eggs. When you've
completed a development cycle, you'll need to run your setup script to
generate a distribution and, perhaps, uploaded it to the Python
package index. If your script uses setuptools, you'll need
setuptools
package index. If your script uses setuptools, you'll need
distribute
in your Python path, which may be an issue if you haven't installed
setuptools
into your Python installation.
distribute
into your Python installation.
The buildout setup command is helpful in a situation like this. It
can be used to run a setup script and it does so with the
setuptools
can be used to run a setup script and it does so with the
distribute
egg in the Python path and with setuptools already imported. The fact
that setuptools is imported means that you can use setuptools-based
commands, like bdist_egg even with packages that don't use setuptools.
...
...
src/zc/buildout/setup.txt
View file @
a18b558c
...
...
@@ -10,7 +10,7 @@ running the script so setuptools-provided commands are available.
If you use a squeaky-clean Python to do your development, the setup
script that would import setuptools because setuptools isn't in the
path. Because buildout requires setuptools and knows where it has
installed a
setuptools egg, it adds the setuptools
egg to the Python
installed a
distribute egg, it adds the distribute
egg to the Python
path before running the script. To run a setup script, use the
buildout setup command, passing the name of a script or a directory
containing a setup script and arguments to the script. Let's look at
...
...
src/zc/buildout/testing.py
View file @
a18b558c
...
...
@@ -39,8 +39,8 @@ from zc.buildout.rmtree import rmtree
fsync
=
getattr
(
os
,
'fsync'
,
lambda
fileno
:
None
)
is_win32
=
sys
.
platform
==
'win32'
setuptools
_location
=
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'
setuptools
'
)).
location
distribute
_location
=
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'
distribute
'
)).
location
def
cat
(
dir
,
*
names
):
path
=
os
.
path
.
join
(
dir
,
*
names
)
...
...
@@ -118,7 +118,7 @@ def _runsetup(setup, *args):
os
.
chdir
(
os
.
path
.
dirname
(
setup
))
zc
.
buildout
.
easy_install
.
call_subprocess
(
[
sys
.
executable
,
setup
]
+
args
,
env
=
dict
(
os
.
environ
,
PYTHONPATH
=
setuptools
_location
))
env
=
dict
(
os
.
environ
,
PYTHONPATH
=
distribute
_location
))
if
os
.
path
.
exists
(
'build'
):
rmtree
(
'build'
)
finally
:
...
...
src/zc/buildout/tests.py
View file @
a18b558c
This diff is collapsed.
Click to expand it.
src/zc/buildout/unzip.txt
View file @
a18b558c
...
...
@@ -17,8 +17,8 @@ By default, zc.buildout doesn't unzip zip-safe eggs.
>>> _ = system(buildout)
>>> ls('eggs')
- demo-0.4c1-py2.4.egg
-
demoneeded-1.2c1-py2.4.egg
d
setuptools
-0.6c8-py2.4.egg
d
demoneeded-1.2c1-py2.4.egg
d
distribute
-0.6c8-py2.4.egg
- zc.buildout.egg-link
This follows the policy followed by setuptools itself. Experience shows
...
...
@@ -50,5 +50,5 @@ default unzipping policy.
>>> ls('eggs')
d demo-0.4c1-py2.4.egg
d demoneeded-1.2c1-py2.4.egg
d
setuptools
-0.6c8-py2.4.egg
d
distribute
-0.6c8-py2.4.egg
- zc.buildout.egg-link
src/zc/buildout/update.txt
View file @
a18b558c
Automatic Buildout Updates
==========================
NOTE: buildout 1.4.4 is a version that has been hacked to prefer itself, and
not upgrade. It is intended as a way for people who have trouble with the new
1.5 line to easily keep from upgrading until they are ready. In the future,
we suggest that you specify the versions of your dependencies using the
standard buildout mechanism
(http://pypi.python.org/pypi/zc.buildout#repeatable-buildouts-controlling-eggs-used).
However, for now, you can use 1.4.4 to easily control your dependencies.
When this file changes because of the hack, the documentation indicates this
with a "HACK" label.
When a buildout is run, one of the first steps performed is to check for
updates to either zc.buildout or
setuptools (HACK: not zc.buildout)
. To
updates to either zc.buildout or
distribute
. To
demonstrate this, we've created some "new releases" of buildout and
setuptools
in a new_releases folder:
distribute
in a new_releases folder:
>>> ls(new_releases)
d
setuptools
-
setuptools
-99.99-py2.4.egg
d
distribute
-
distribute
-99.99-py2.4.egg
d zc.buildout
- zc.buildout-99.99-py2.4.egg
...
...
@@ -36,7 +26,7 @@ Let's update the sample buildout.cfg to look in this area:
... recipe = showversions
... """ % dict(new_releases=new_releases))
We'll also include a recipe that echos the versions of
setuptools
and
We'll also include a recipe that echos the versions of
distribute
and
zc.buildout used:
>>> mkdir(sample_buildout, 'showversions')
...
...
@@ -51,7 +41,7 @@ zc.buildout used:
... pass
...
... def install(self):
... for project in 'zc.buildout', '
setuptools
':
... for project in 'zc.buildout', '
distribute
':
... req = pkg_resources.Requirement.parse(project)
... print project, pkg_resources.working_set.find(req).version
... return ()
...
...
@@ -71,22 +61,21 @@ zc.buildout used:
Now if we run the buildout, the buildout will upgrade itself to the
new versions found in new releases
(HACK: only setuptools)
:
new versions found in new releases:
>>> print system(buildout),
Getting distribution for '
setuptools
'.
Got
setuptools
99.99.
Getting distribution for '
distribute
'.
Got
distribute
99.99.
Upgraded:
setuptools
version 99.99;
distribute
version 99.99;
restarting.
Generated script '/sample-buildout/bin/buildout'.
Develop: '/sample-buildout/showversions'
Installing show-versions.
zc.buildout 1.4.4
setuptools
99.99
distribute
99.99
Our buildout script has been updated to use the new eggs (HACK: only for
setuptools):
Our buildout script has been updated to use the new eggs:
>>> cat(sample_buildout, 'bin', 'buildout')
#!/usr/local/bin/python2.7
...
...
@@ -94,7 +83,7 @@ setuptools):
import sys
sys.path[0:0] = [
'/sample-buildout/eggs/zc.buildout-1.4.4-py2.4.egg',
'/sample-buildout/eggs/
setuptools
-99.99-py2.4.egg',
'/sample-buildout/eggs/
distribute
-99.99-py2.4.egg',
]
<BLANKLINE>
import zc.buildout.buildout
...
...
@@ -103,8 +92,8 @@ setuptools):
zc.buildout.buildout.main()
Now, let's recreate the sample buildout. If we specify constraints on
the versions of zc.buildout and
setuptools
to use, running the buildout
will install earlier versions of these packages
(HACK: only setuptools)
:
the versions of zc.buildout and
distribute
to use, running the buildout
will install earlier versions of these packages:
>>> write(sample_buildout, 'buildout.cfg',
... """
...
...
@@ -114,7 +103,7 @@ will install earlier versions of these packages (HACK: only setuptools):
... parts = show-versions
... develop = showversions
... zc.buildout-version = < 99
...
setuptools
-version = < 99
...
distribute
-version = < 99
...
... [show-versions]
... recipe = showversions
...
...
@@ -124,13 +113,13 @@ Now we can see that we actually "upgrade" to an earlier version.
>>> print system(buildout),
Upgraded:
setuptools
version 0.6;
distribute
version 0.6;
restarting.
Generated script '/sample-buildout/bin/buildout'.
Develop: '/sample-buildout/showversions'
Updating show-versions.
zc.buildout 1.0.0
setuptools
0.6
distribute
0.6
There are a number of cases, described below, in which the updates
don't happen.
...
...
@@ -153,7 +142,7 @@ We won't upgrade in offline mode:
Develop: '/sample-buildout/showversions'
Updating show-versions.
zc.buildout 1.0.0
setuptools
0.6
distribute
0.6
Or in non-newest mode:
...
...
@@ -161,7 +150,7 @@ Or in non-newest mode:
Develop: '/sample-buildout/showversions'
Updating show-versions.
zc.buildout 1.0.0
setuptools
0.6
distribute
0.6
We also won't upgrade if the buildout script being run isn't in the
buildouts bin directory. To see this we'll create a new buildout
...
...
@@ -182,8 +171,8 @@ directory:
Creating directory '/sample_buildout2/parts'.
Creating directory '/sample_buildout2/eggs'.
Creating directory '/sample_buildout2/develop-eggs'.
Getting distribution for '
setuptools
'.
Got
setuptools
99.99.
Getting distribution for '
distribute
'.
Got
distribute
99.99.
Not upgrading because not running a local buildout command.
>>> ls('bin')
src/zc/buildout/upgrading_distribute.txt
View file @
a18b558c
Installing
setuptools/
distribute
---------------------
-----------
Installing distribute
---------------------
Some initial test setup:
...
...
@@ -7,15 +7,15 @@ Some initial test setup:
>>> import zc.buildout
>>> dest = tmpdir('sample-install')
Setuptools (0.6something) is packaged as an ``.egg``. So when installing it,
the egg is downloaded and used. Distribute is packaged as a tarball, which
makes an easy_install call necessary. In older versions of buildout, the
``_call_easy_install()`` method would call ``_get_dist()`` to get hold of the
setuptools path for calling easy_install. When an updated "distribute" was
found, this would try an install again, leading to an
infinite recursion.
Distribute is packaged as a tarball, which makes an easy_install call
necessary. In older versions of buildout, the
``_call_easy_install()`` method would call ``_get_dist()`` to get hold
of the setuptools path for calling easy_install. When an updated
"distribute" was found, this would try an install again, leading to an
infinite recursion.
The solution is to just use the
setuptools
location found at import time, like
happens with the buildout and
setuptools
location that is inserted in scripts'
The solution is to just use the
distribute
location found at import time, like
happens with the buildout and
distribute
location that is inserted in scripts'
paths.
We test this corner case by patching the ``_get_dist()`` call:
...
...
@@ -23,7 +23,7 @@ We test this corner case by patching the ``_get_dist()`` call:
>>> def mock_get_dist(requirement, ws, always_unzip):
... raise RuntimeError("We should not get called")
When installing
setuptools
itself, we expect the "Getting dist" message not to
When installing
distribute
itself, we expect the "Getting dist" message not to
be printed. We call ``_call_easy_install()`` directly and get an error
because of a non-existing tarball, but that's the OK for this corner case
test: we only want to test that ``_get_dist()`` isn't getting called:
...
...
@@ -34,7 +34,7 @@ test: we only want to test that ``_get_dist()`` isn't getting called:
... @property
... def project_name(self):
... # Testing corner case: there *is* actually
... # a newer
setuptools
package on pypi than we
... # a newer
distribute
package on pypi than we
... # are running with, so it really installs it
... # and compares project_name. We're past the
... # point that we're testing, so we just raise
...
...
@@ -49,7 +49,7 @@ test: we only want to test that ``_get_dist()`` isn't getting called:
... index=link_server+'index/',
... always_unzip=True)
>>> installer._get_dist = mock_get_dist
>>> installer._call_easy_install('
setuptools
', None, dest, dist)
>>> installer._call_easy_install('
distribute
', None, dest, dist)
Traceback (most recent call last):
...
UserError: Couldn't install: nonexisting.tgz
zc.recipe.egg_/src/zc/recipe/egg/README.txt
View file @
a18b558c
...
...
@@ -72,8 +72,8 @@ Now, if we look at the buildout eggs directory:
>>> ls(sample_buildout, 'eggs')
- demo-0.2-py2.3.egg
-
demoneeded-1.2c1-py2.3.egg
-
setuptools
-0.6-py2.3.egg
d
demoneeded-1.2c1-py2.3.egg
-
distribute
-0.6-py2.3.egg
- zc.buildout-1.0-py2.3.egg
We see that we got an egg for demo that met the requirement, as well
...
...
@@ -261,8 +261,8 @@ We didn't get an update for demo:
>>> ls(sample_buildout, 'eggs')
- demo-0.2-py2.3.egg
-
demoneeded-1.2c1-py2.3.egg
-
setuptools
-0.6-py2.3.egg
d
demoneeded-1.2c1-py2.3.egg
-
distribute
-0.6-py2.3.egg
- zc.buildout-1.0-py2.3.egg
If we run the buildout on the default online and newest modes,
...
...
@@ -279,8 +279,8 @@ Then we'll get a new demo egg:
>>> ls(sample_buildout, 'eggs')
- demo-0.2-py2.3.egg
- demo-0.4c1-py2.3.egg
-
demoneeded-1.2c1-py2.3.egg
-
setuptools
-0.6-py2.4.egg
d
demoneeded-1.2c1-py2.3.egg
-
distribute
-0.6-py2.4.egg
- zc.buildout-1.0-py2.4.egg
The script is updated too:
...
...
zc.recipe.egg_/src/zc/recipe/egg/api.txt
View file @
a18b558c
...
...
@@ -103,7 +103,7 @@ computed by the egg recipe by looking at .installed.cfg:
__buildout_installed__ =
__buildout_signature__ = sample-6aWMvV2EJ9Ijq+bR8ugArQ==
zc.recipe.egg-cAsnudgkduAa/Fd+WJIM6Q==
setuptools
-0.6-py2.4.egg
distribute
-0.6-py2.4.egg
zc.buildout-+rYeCcmFuD1K/aB77XTj5A==
_b = /sample-buildout/bin
_d = /sample-buildout/develop-eggs
...
...
zc.recipe.egg_/src/zc/recipe/egg/egg.py
View file @
a18b558c
...
...
@@ -152,11 +152,11 @@ class Scripts(Eggs):
if
get_bool
(
options
,
'dependent-scripts'
):
# Generate scripts for all packages in the working set,
# except
setuptools
.
# except
distribute
.
reqs
=
list
(
reqs
)
for
dist
in
ws
:
name
=
dist
.
project_name
if
name
!=
'
setuptools
'
and
name
not
in
reqs
:
if
name
!=
'
distribute
'
and
name
not
in
reqs
:
reqs
.
append
(
name
)
return
zc
.
buildout
.
easy_install
.
scripts
(
...
...
zc.recipe.egg_/src/zc/recipe/egg/tests.py
View file @
a18b558c
...
...
@@ -45,7 +45,7 @@ def test_suite():
zc
.
buildout
.
tests
.
normalize_bang
,
(
re
.
compile
(
'zc.buildout(-
\
S+)?[.]egg(-li
n
k)?'
),
'zc.buildout.egg'
),
(
re
.
compile
(
'[-d]
setuptools-[^-]+-'
),
'setuptools
-X-'
),
(
re
.
compile
(
'[-d]
distribute-[^-]+-'
),
'distribute
-X-'
),
(
re
.
compile
(
r'eggs\\\\demo'
),
'eggs/demo'
),
(
re
.
compile
(
r'[a-zA-Z]:\\\\foo\\\\bar'
),
'/foo/bar'
),
])
...
...
@@ -59,7 +59,7 @@ def test_suite():
(
re
.
compile
(
'__buildout_signature__ = '
'sample-
\
S+
\
s+'
'zc.recipe.egg-
\
S+
\
s+'
'
setuptools
-
\
S+
\
s+'
'
distribute
-
\
S+
\
s+'
'zc.buildout-
\
S+
\
s*'
),
'__buildout_signature__ = sample- zc.recipe.egg-'
),
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment