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
6
Merge Requests
6
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
slapos.buildout
Commits
d38b743b
Commit
d38b743b
authored
May 16, 2020
by
Godefroid Chapelle
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Problem: Documentation mentions bootstrap-buildout
Solution: Remove it, mention `pip`
parent
a82a8025
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
15 additions
and
126 deletions
+15
-126
DEVELOPERS.txt
DEVELOPERS.txt
+1
-17
doc/topics/bootstrapping.rst
doc/topics/bootstrapping.rst
+12
-105
src/zc/buildout/easy_install.py
src/zc/buildout/easy_install.py
+2
-4
No files found.
DEVELOPERS.txt
View file @
d38b743b
...
...
@@ -11,8 +11,7 @@ When you're developing buildout itself, you need to know two things:
tests so you may want to temporarily rename it so that it does not get in
the way.
- Don't bootstrap with ``python bootstrap/bootstrap.py`` but with ``python
dev.py``.
- Bootstrap with with ``python dev.py``.
- Run buildout with -U, to ignore user (default) settings which can interfere
with using the development version
...
...
@@ -44,21 +43,6 @@ zc.buildout's setup.py and changelog is in the same directory as this
zc.recipe.egg, including setup.py and a separate changelog, is in the
``zc.recipe.egg_`` subdirectory.
A third item is the bootstrap.py file in ``bootstrap/bootstrap.py``. The
canonical location is at https://bootstrap.pypa.io/bootstrap-buildout.py,
(though it is unfortunate that it isn't named just ``bootstrap.py``). This
file is pulled automatically every 15 minutes from the bootstrap-release
branch. When a new buildout release is made, **the releaser** should update
the bootstrap-release branch, too.
The http://downloads.buildout.org/2/bootstrap.py location doesn't need to be
updated manually: it is a redirect now, to
https://bootstrap.pypa.io/bootstrap-buildout.py .
If there are changes to bootstrap.py, be sure to update the date in the
``__version__`` attribute and to record the bootstrap change (including the
new date/version) in zc.buildout's changelog.
When releasing, make sure you also build a (universal) wheel in addition to
the regular .tar.gz::
...
...
doc/topics/bootstrapping.rst
View file @
d38b743b
...
...
@@ -27,15 +27,24 @@ Avoid modifying the python environment.
existed, it might not have been possible to modify the environment
without building Python from source.
Unfortunately, doing this requires :ref:`using a bootstrap script
<using-a-bootstrap-script>`.
Installing from scratch
=======================
We recommend to install ``buildout`` via ``pip install`` inside a ``virtualenv``:
.. code-block:: console
virtualenv my_buildout
cd my_buildout
bin/pip install zc.buildout
Local bootstrapping using the ``bootstrap`` command
===================================================
You can use the :ref:`bootstrap command <bootstrap-command>` of a
``buildout`` script installed in your Python environment to boostrap
the
buildout in the current directory:
a new
buildout in the current directory:
.. code-block:: console
...
...
@@ -61,68 +70,6 @@ can use their ``buildout`` scripts:
In this case, the buildout being bootstrapped will have the same
Python environment as the buildout that was used to bootstrap it.
.. _using-a-bootstrap-script:
Using a bootstrapping script
============================
If you download::
https://bootstrap.pypa.io/bootstrap-buildout.py
.. -> url
And then run it:
.. code-block:: console
python bootstrap-buildout.py
.. -> src
>>> os.mkdir('fresh'); os.chdir('fresh')
>>> eqs(os.listdir("."))
>>> from six.moves.urllib import request
>>> f = request.urlopen(url)
>>> write(f.read().decode('ascii'), 'bootstrap-buildout.py')
>>> f.close()
>>> write("[buildout]\nparts=\n", 'buildout.cfg')
>>> import subprocess, sys
>>> src = src.replace('python', sys.executable).split()
>>> p = subprocess.Popen(
... src, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
... env=dict(HOME='zzzzz'))
>>> if p.wait():
... print(p.stderr.read())
>>> eqs(os.listdir("."), 'bootstrap-buildout.py',
... 'buildout.cfg', 'eggs', 'bin', 'develop-eggs', 'parts')
>>> os.chdir('..')
>>> p.stdout.close()
>>> p.stderr.close()
It will download the software needed to run Buildout and install it in
the current directory.
This has been the traditional approach to bootstrapping Buildout.
It was the best approach for a long time because the ``pip`` and
``easy_install`` commands usually weren't available. In the early
days, if ``easy_install`` was installed, it was likely to have an
incompatible version of setuptools, because Buildout and setuptools
were evolving rapidly, sometimes in lock step.
This approach fails from time to time, due to changes in setuptools or
`the package index <https://pypi.org/>`_ and has been a
source of breakage when automated systems depended on it.
It's also possible that this approach will stop being supported.
Buildout's bootstrapping script relies on setuptools' bootstrap
script, which was used to bootstrap ``easy_install``. Now that pip is
ubiquitous, there's no reason to bootstrap ``easy_install`` and
setuptools' bootstrapping script exists solely to support Buildout.
At some point, that may become too much of a maintenance burden, and
there may not be Buildout volunteers motivated to create a new
bootstrapping solution.
.. _init-generates-buildout.cfg:
Bootstrapping requires a ``buildout.cfg``, ``init`` creates one
...
...
@@ -147,46 +94,6 @@ If you don't have one, you can use the :ref:`init command
... 'buildout.cfg', 'out', 'eggs', 'bin', 'develop-eggs', 'parts')
>>> os.chdir('..')
This can be used with the bootstrapping script as well:
.. code-block:: console
python bootstrap-buildout.py init
.. -> src
>>> os.mkdir('fresh2'); os.chdir('fresh2')
>>> eqs(os.listdir("."))
>>> f = request.urlopen(url)
>>> write(f.read().decode('ascii'), 'bootstrap-buildout.py')
>>> f.close()
>>> src = src.replace('python', sys.executable).split()
>>> p = subprocess.Popen(
... src, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
... env=dict(HOME='zzzzz'))
>>> if p.wait():
... print(p.stderr.read())
>>> eqs(os.listdir("."), 'bootstrap-buildout.py',
... 'buildout.cfg', 'eggs', 'bin', 'develop-eggs', 'parts')
>>> p.stdout.close()
>>> p.stderr.close()
This creates an empty Buildout configuration:
.. code-block:: ini
[buildout]
parts =
.. -> src
>>> eq(src, read('buildout.cfg'))
>>> os.chdir('..')
>>> os.chdir('init')
>>> eq(src, read('buildout.cfg'))
>>> os.chdir('..')
If you know you're going to use some packages, you can supply
requirements on the command line after ``init``:
...
...
src/zc/buildout/easy_install.py
View file @
d38b743b
...
...
@@ -86,10 +86,8 @@ has_distribute = pkg_resources.working_set.find(
has_setuptools
=
pkg_resources
.
working_set
.
find
(
pkg_resources
.
Requirement
.
parse
(
'setuptools'
))
is
not
None
if
has_distribute
and
not
has_setuptools
:
sys
.
exit
(
"zc.buildout 2 needs setuptools, not distribute."
" Are you using an outdated bootstrap.py? Make sure"
" you have the latest version downloaded from"
" https://bootstrap.pypa.io/bootstrap-buildout.py"
)
sys
.
exit
(
"zc.buildout 3 needs setuptools, not distribute."
"Did you properly install with pip in a virtualenv ?"
)
# Include buildout and setuptools eggs in paths. We get this
# initially from the entire working set. Later, we'll use the install
...
...
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