Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.

com

DevOps in Python: Infrastructure as Python 2nd

Edition Moshe Zadka

https://ebookmeta.com/product/devops-in-python-
infrastructure-as-python-2nd-edition-moshe-zadka-2/

OR CLICK HERE

DOWLOAD EBOOK

Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

Moshe Zadka
DevOps in Python
Infrastructure as Python
2nd ed.
Moshe Zadka
Belmont, CA, USA

ISBN 978-1-4842-7995-3 e-ISBN 978-1-4842-7996-0

https://doi.org/10.1007/978-1-4842-7996-0

© Moshe Zadka 2022

Apress Standard

The use of general descriptive names, registered names, trademarks,

service marks, etc. in this publication does not imply, even in the
absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general
use.

The publisher, the authors and the editors are safe to assume that the
advice and information in this book are believed to be true and accurate
at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, expressed or implied, with respect to the
material contained herein or for any errors or omissions that may have
been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.

This Apress imprint is published by the registered company APress

Media, LLC, part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY
10004, U.S.A.
Dedicated to A and N, my favorite two projects
Introduction
Python began as a language to automate an operating system: the
Amoeba. A typical Unix shell would be ill-suited since it had an API, not
just textual file representations. The Amoeba OS is a relic now.
However, Python continues to be a useful tool for automation of
operations—the heart of typical DevOps work.
It is easy to learn and easy to write readable code is a necessity
when a critical part of the work is responding to a 4 a.m. alert and
modifying some misbehaving program.
It has powerful bindings to C and C++, the universal languages of
the operating system—and yet is natively memory-safe, leading to few
crashes at the automation layer.
Finally, although not true when it was created, Python is one of the
most popular languages. This means that it is relatively easy to hire
people with Python experience and easy to get training materials and
courses for people who need to learn on the job.
This book guides you through how to take advantage of Python to
automate operations.
To get the most out of the book, you need to be somewhat familiar
with Python. If you are new to Python, there are many great resources
to learn it, including the official Python tutorial at docs.python.org. You
also need to be somewhat familiar with Unix-like operating systems like
Linux, especially how to use the command line.
Any source code or other supplementary material referenced by the
author in this book is available to readers on GitHub
(github.com/apress). For more detailed information, please visit
http://www.apress.com; https://github.com/Apress/DevOps-in-
Python-2nd-ed-
Acknowledgments
Thanks to my wife, Jennifer Zadka, without whose support I could not
have written this book.
Thanks to my parents, Yaacov and Pnina Zadka, who taught me how
to learn.
Thanks to my advisor, Yael Karshon, who taught me how to write.
Thanks to Mahmoud Hashemi for inspiration and encouragement.
Thanks to Mark Williams for being there for me.
Thanks to Glyph Lefkowitz for teaching me about Python,
programming, and being a good person.
Thanks to Brennon Church and Andrea Ross, who supported my
personal growth and learning journey.
Table of Contents
Chapter 1:​Installing Python
1.​1 OS Packages
1.​2 Using pyenv
1.​3 Building Python from Source
1.​4 PyPy
1.​5 Anaconda
1.​6 Summary
Chapter 2:​Packaging
2.​1 Virtual Environments
2.​2 pip
2.​3 Setup and Wheels
2.​4 Binary Wheels
2.5 manylinux Wheels
2.​5.​1 Self-Contained Wheels
2.​5.​2 Portable Wheels
2.​5.​3 manylinux Containers
2.​5.​4 Installing manylinux Wheels
2.​6 tox
2.​6.​1 One Environment
2.​6.​2 Multiple Environments
2.​6.​3 Multiple Differently Configured Environments
2.​7 Pip Tools
2.​8 Poetry
2.​8.​1 Installing
2.​8.​2 Creating
 2.​8.​3 Dependencies
2.​8.​4 Developing
2.​8.​5 Building
2.​9 Pipenv
2.​10 DevPI
2.​11 pex and shiv
2.​11.​1 pex
2.​11.​2 shiv
2.​12 Summary
Chapter 3:​Interactive Usage
3.​1 Native Console
3.​2 The Code Module
3.​3 ptpython
3.​4 IPython
3.​5 JupyterLab
3.​6 Summary
Chapter 4:​OS Automation
4.​1 Files
4.​2 Processes
4.​3 Networking
4.​4 Summary
Chapter 5:​Testing
5.​1 Unit Testing
5.​2 Mocks, Stubs, and Fakes
5.​3 Testing Files
5.​3.​1 Testing with Subdirectories
 5.​3.​2 Accelerating Tests with eatmydata
5.​3.​3 Accelerating Tests with tmpfs
5.​4 Testing Processes
5.​5 Testing Networking
5.​6 Testing HTTP Clients
Chapter 6:​Text Manipulation
6.​1 Bytes, Strings, and Unicode
6.​2 Strings
6.​3 Regular Expressions
6.​4 JSON
6.​5 CSV
6.​6 Summary
Chapter 7:​HTTPX
7.​1 Clients
7.​2 REST
7.​3 Security
7.​4 Authentication
7.​5 Async client
7.​6 Summary
Chapter 8:​Cryptography
8.​1 Fernet
8.​2 PyNaCl
8.​3 Passlib
8.​4 TLS Certificates
8.​5 Summary
Chapter 9:​Paramiko
 9.​1 SSH Security
9.​2 Client Keys
9.​3 Host Identity
9.​4 Connecting
9.​5 Running Commands
9.​6 Remote Files
9.​6.​1 Metadata Management
9.​6.​2 Upload
9.​6.​3 Download
9.​7 Summary
Chapter 10:​SaltStack
10.​1 Salt Basics
10.​2 Salt Concepts
10.​3 Salt Formats
10.​4 Salt Extensions
10.​4.​1 States
10.​4.​2 Execution
10.​4.​3 Utility
10.​4.​4 Extra Third-Party Dependencies
10.​5 Summary
Chapter 11:​Ansible
11.​1 Ansible Basics
11.​2 Ansible Concepts
11.​3 Ansible Extensions
11.​4 Summary
Chapter 12:​Containers
 12.​1 Choosing a Base Image
12.​1.​1 GNU C Library Support
12.​1.​2 Long-Term Support
12.​1.​3 Avoiding Unexpected Changes
12.​2 Installing the Python Interpreter
12.​2.​1 conda
12.​2.​2 Third-Party Repositories
12.​2.​3 Building Python in the Container
12.​2.​4 Python Base Image
12.​3 Installing Python Applications
12.​4 Optimizing Container Build Cache
12.​5 Rebuilding Containers
12.​6 Container Security
12.​7 Summary
Chapter 13:​Amazon Web Services
13.​1 Security
13.​1.​1 Configuring Access Keys
13.​1.​2 Creating Short-Term Tokens
13.​2 Elastic Computing Cloud (EC2)
13.​2.​1 Regions
13.​2.​2 Amazon Machine Images
13.​2.​3 SSH Keys
13.​2.​4 Bringing up Machines
13.​2.​5 Securely Logging In
13.​2.​6 Building Images
13.​3 Simple Storage Service (S3)
 13.​3.​1 Managing Buckets
13.​4 Summary
Chapter 14:​Kubernetes
14.​1 Pods
14.​1.​1 Liveness and Readiness
14.​1.​2 Configuration
14.​1.​3 Python Sidecars
14.​2 REST API
14.​3 Operators
14.​3.​1 Permissions
14.​3.​2 Custom Types
14.​3.​3 Retrieval
14.​3.​4 Goal State
14.​3.​5 Comparison
14.​3.​6 Reconciliation
14.​3.​7 Combining the Pieces
14.​4 Summary
Chapter 15:​Terraform
15.​1 JSON Syntax
15.​2 Generating Terraform Configurations
15.​3 Summary
Index
About the Author
Moshe Zadka
has been involved in the Linux
community since 1998, helping in Linux
“installation parties.” He has been
programming Python since 1999 and has
contributed to the core Python
interpreter. Moshe has been a
DevOps/SRE since before those terms
existed, caring deeply about software
reliability, build reproducibility, and
more. He has worked in companies as
small as three people and as big as tens
of thousands—and usually in a position
where software meets system
administration.
About the Technical Reviewer
Martyn Bristow
is a software developer in the United
Kingdom. He began using Python as a
researcher but is now an experienced
broad user of Python for data analysis,
software test automation, and DevOps.
He currently builds data analysis web
apps in Python deployed to Kubernetes.
You can find Martyn on GitHub
@martynbristow.
© The Author(s), under exclusive license to APress Media, LLC, part of Springer
Nature 2022
M. Zadka, DevOps in Python
https://doi.org/10.1007/978-1-4842-7996-0_1
1. Installing Python
Moshe Zadka1
(1) Belmont, CA, USA

Before you can use Python, you need to install it. Some operating
systems, such as macOS and some Linux variants, have Python
preinstalled. Those versions of Python, colloquially called system
Python, often make poor defaults for people who want to develop in
Python.
The version of Python installed is often behind the latest practices.
System integrators often patch Python in ways that can lead to
surprises. For example, Debian-based Python is often missing modules
like venv and ensurepip. macOS Python links against a Mac shim
around its native SSL library. Those things mean, especially when
starting and consuming FAQs and web resources, it is better to install
Python from scratch.
This chapter covers a few ways to do so and the pros and cons of
each.
1.1 OS Packages
Volunteers have built ready-to-install packages for some of the more
popular operating systems.
The most famous is the deadsnakes PPA (Personal Package
Archives). The dead in the name refers to the fact that those packages
are already built—with the metaphor that sources are “alive.” Those
packages are built for Ubuntu and usually support all the versions of
Ubuntu that are still supported upstream. Getting those packages is
done with a simple

$ sudo add-apt-repository ppa:deadsnakes/ppa

$ sudo apt update

On macOS, the Homebrew third-party package manager has up-to-

date Python packages. An introduction to Homebrew is beyond the
scope of this book. Homebrew being a rolling release, the Python
version is upgraded from time to time. While this means that it is a
useful way to get an up-to-date Python, it makes it a poor target for
reliably distributing tools.
It also has some downsides for doing day-to-day development. Since
it upgrades quickly after a new Python release, development
environments can break quickly and without warning. It also means
that sometimes code can stop working; even if you are careful to watch
upcoming Python versions for breaking changes, not all packages will.
Homebrew is a good fit when needing a well-built up-to-date Python
interpreter for a one-off task. Writing a quick script to analyze data, or
automate some APIs, is a good use of Homebrew Python.
Finally, for Windows, it is possible to download an installer from
Python.org for any version of Python.
1.2 Using pyenv
pyenv tends to offer the highest return on investment for installing
Python for local development. The initial setup does have some
subtleties. However, it allows installing many side-by-side Python
versions as needed. It also allows you to manage how each is accessed
—either using a per-user default or a per-directory default.
Installing pyenv itself depends on the operating system. On a
macOS, the easiest way is to install it via Homebrew. Note that in this
case, pyenv itself might need to be upgraded to install new versions of
Python.
On a Unix-based operating system, such as Linux or FreeBSD, the
easiest way to install pyenv is by using the curl|bash command.

$ PROJECT=https://github.com/pyenv/pyenv-installer
\
PATH=raw/master/bin/pyenv-installer \
curl -L $PROJECT/PATH | bash

Of course, this comes with its own security issues and could be
replaced with a two-step process where you can inspect the shell script
before running or even use git-checkout to pin to a specific revision.

$ git clone https://github.com/pyenv/pyenv-

installer
$ cd pyenv-installer
$ bash pyenv-installer

Unfortunately, pyenv does not work on Windows.

After installing pyenv, it is useful to integrate it with the running
shell. You do this by adding the following to the shell initialization file
(e.g., .bash_profile).

export PATH="~/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
 This allows pyenv to properly intercept all the necessary
commands.
pyenv separates the notion of installed interpreters from available
interpreters. Enter the following to install a version.

$ pyenv install <version>

For CPython, <version> is the version number, such as 3.6.6 or

3.7.0rc1.
An installed version is distinct from an available version. Versions
are available globally (for a user) by using

$ pyenv global 3.7.0

or locally by using

$ pyenv local 3.7.0

Local means they are available in a given directory. This is done by

putting a python-version.txt file in this directory. This is important for
version-controlled repositories, but a few different strategies are used
to manage those. One strategy is to add this file to the ignored list. This
is useful for heterogeneous teams or open source projects. Another
strategy is to check in the file so that the same version of Python is used
in the repository.
Note that since pyenv is designed to install side-by-side versions of
Python, it has no concept of upgrading Python. A newer Python version
needs to be installed with pyenv and then set as the default.
By default, pyenv installs non-optimized versions of Python. If
optimized versions are needed, enter the following.

env PYTHON_CONFIGURE_OPTS="--enable-shared
--enable-optimizations
--with-computed-gotos
--with-lto
--enable-ipv6" pyenv
install
 Let’s build a version that is pretty similar to binary versions from
python.org.
1.3 Building Python from Source
The main challenge in building Python from source is that, in some
sense, it is too forgiving. It is all too easy to build it with one of the built-
in modules disabled because its dependency was not detected. This is
why it is important to know which dependencies are fragile and how to
make sure a local installation is good.
The first fragile dependency is SSL. It is disabled by default and
must be enabled in Modules/Setup.dist. Carefully follow the
instructions there about the location of the OpenSSL library. If you have
installed OpenSSL via system packages, it is usually in /usr/. If you
have installed it from source, it is usually in /usr/local.
The most important thing is to know how to test for it. When
Python is done building, run ./python.exe -c 'import _ssl'.
That .exe is not a mistake; this is how the build process calls the newly
built executable, which is renamed to Python during installation. If this
succeeds, the SSL module was built correctly.
Another extension that can fail to build is SQLite. Since it is a built-
in, many third-party packages depend on it, even if you are not using it
yourself. This means a Python installation without the SQLite module is
pretty broken. Test it by running ./python.exe -c 'import
sqlite3'.
In a Debian-based system (such as Ubuntu), libsqlite3-dev is
required for this to succeed. In a Red Hat-based system (such as Fedora
or CentOS), libsqlite3-dev is required for this to succeed.
Next, check for _ctypes with ./python.exe -c 'import
_ctypes'. If this fails, likely, the libffi headers are not installed.
Finally, remember to run the built-in regression test suite after
building from source. This ensures that there have been no silly
mistakes while building the package.
1.4 PyPy
The usual implementation of Python is sometimes known as CPython to
distinguish it from the language proper. The most popular alternative
implementation is PyPy, a Python-based JIT implementation of Python
in Python. Because it has a dynamic JIT (just-in-time) compilation to
assembly, it can sometimes achieve phenomenal speed-ups (three times
or even ten times) over regular Python.
There are sometimes challenges in using PyPy. Many tools and
packages are tested only with CPython. However, sometimes spending
the effort to check if PyPy is compatible with the environment is worth
it if performance matters.
There are a few subtleties in installing Python from source. While it
is theoretically possible to translate using CPython, in practice, the
optimizations in PyPy mean that translating using PyPy works on more
reasonable machines. Even when installing from source, it is better to
first install a binary version to bootstrap.
The bootstrapping version should be PyPy, not PyPy3. PyPy is
written in the Python 2 dialect, which is one of the only cases where
worrying about the deprecation is irrelevant since PyPy is a Python 2
dialect interpreter. PyPy3 is the Python 3 dialect implementation,
which is usually better in production as most packages are slowly
dropping support for Python 2.
The latest PyPy3 supports 3.5 features of Python, as well as f-
strings. However, the latest async features, added in Python 3.6, do not
work.
1.5 Anaconda
The closest to a system Python that is still reasonable for use as a
development platform is Anaconda, a metadistribution. It is, in essence,
an operating system on top of the operating system. Anaconda has its
grounding in the scientific computing community, and so its Python
comes with easy-to-install modules for many scientific applications.
Many of these modules are non-trivial to install from PyPI, requiring a
complicated build environment.
It is possible to install multiple Anaconda environments on the
same machine. This is handy when needing different Python versions
or different versions of PyPI modules.
To bootstrap Anaconda, you can use the bash installer available at
https://conda.io/miniconda.html. The installer also modifies
~/.bash_profile to add the path to conda, the installer.
conda environments are created using conda create --name
<name> and activated using source conda activate <name>.
There is no easy way to use inactivated environments. It is possible to
create a conda environment while installing packages: conda create
--name some-name python. You can specify the version using = –
conda create --name some-name python=3.5. It is also
possible to install more packages into a conda environment, using
conda install package[=version], after the environment has
been activated. Anaconda has a lot of prebuilt Python packages,
especially ones that are non-trivial to build locally. This makes it a good
choice if those packages are important to your use case.
1.6 Summary
Running a Python program requires an interpreter installed on the
system. Depending on the operating system and the versions, there are
several different ways to install Python. Using the system Python is a
problematic option. On macOS and Unix systems, using pyenv is almost
always the preferred option. On Windows, using the prepackaged
installers from Python.org is often a good idea.
© The Author(s), under exclusive license to APress Media, LLC, part of Springer
Nature 2022
M. Zadka, DevOps in Python
https://doi.org/10.1007/978-1-4842-7996-0_2
2. Packaging
Moshe Zadka1
(1) Belmont, CA, USA

One of the main strengths of Python is the ecosystem, the third-party

packages on PyPI. There are packages to do anything from running
computations in parallel on GPUs for machine learning to reducing the
boilerplate needed for writing classes. This means that a lot of the practical
work with Python is handling the third-party dependencies.
The current packaging tooling is pretty good, but things have not
always been this way. It is important to understand which best practices
are antiquated rituals based on faulty assumptions but have some merit
and are actually good ideas.
When dealing with packaging, there are two ways to interact. One is to
be a consumer wanting to use the functionality of a package. Another is to
be the producer, publishing a package. These describe, usually, different
development tasks, not different people.
It is important to have a solid understanding of the consumer side of
packages before moving to production. If the goal of a package publisher is
to be useful to the package user, it is crucial to imagine the last mile before
starting to write a single line of code.
2.1 Virtual Environments
Virtual environments are often misunderstood because the concept of
environments is not clear. A Python environment refers to the root of the
Python installation. The reason an environment is important is because of
the lib/site-packages subdirectory of that root. The lib/site-
packages subdirectory is where third-party packages are installed.
The most popular tool to add packages to an environment is pip, which
is covered in the next section. Before using pip, it is important to
understand how virtual environments work.
A real environment is based on Python installation, which means that to
get a new real environment, a new Python must be installed and often
rebuilt. This is sometimes an expensive proposition.
The advantage of a virtual environment is that it is cheap to set up and
tear down. Some modern Python tooling takes advantage of that, setting up
and tearing down virtual environments as a normal part of their operation.
Setting up and tearing down virtual environments, being cheap and fast, is
also a common part of Python developer workflow.
A virtual environment copies the minimum necessary out of the real
environment to mislead Python into thinking it has a new root. The precise
file structure is less important than remembering that the command to
create a virtual environment is simple and fast.
Here, simple means that all the command does is copy some files and
perhaps make a few symbolic links. Because of that, there are a few failure
modes—mostly when file creation fails because of permission issues or a
full disk.
There are two ways to use virtual environments: activated and
inactivated. To use an inactivated virtual environment, which is most
common in scripts and automated procedures, you explicitly call Python
from the virtual environment.
This means that a virtual environment in /home/name/venvs/my-
special-env calling /home/name/venvs/my-special-
env/bin/python has a Python process that uses this environment. For
example, /home/name/venvs/my-special-env/bin/python -m
pip runs pip but installs in the virtual environment.
Note that entrypoint–based scripts are installed alongside Python,
so running /home/name/venvs/my-special-env/bin/pip also
installs packages in the virtual environment.
The other way to use a virtual environment is to activate it. Activating a
virtual environment in a bash-like shell means sourcing its activated script.

$ source /home/name/venvs/my-special-env/bin/activate

The sourcing sets a few environment variables, only one of which is

important. The important variable is PATH, which gets prefixed by
/home/name/venvs/my-special-env/bin. This means that
commands like python or pip are found there first. Two cosmetic
variables are set. $VIRTUAL_ENV points to the root of the environment.
This is useful in management scripts that want to be aware of virtual
environments. PS1 is prefixed with (my-special-env), which is useful
for visualizing the virtual environment while working interactively in the
console.
It is generally a good practice to only install third-party packages inside
a virtual environment. Combined with the fact that virtual environments
are cheap, if one gets into a bad state, it is best to remove the whole
directory and start from scratch.
For example, imagine a bad package install that causes the Python start-
up to fail. Even running pip uninstall is impossible since pip fails on
start-up. However, the cheapness means you can remove the whole virtual
environment and re-create it with a good set of packages.
A modern practice is to move increasingly toward treating virtual
environments as semi-immutable. After creating them, there is a single
stage for installing all required packages. Instead of modifying the virtual
environment if an upgrade is required, destroy the environment, re-create,
and reinstall.
The modern way to create virtual environments is to use the venv
standard library module. This only works on Python 3. Since Python 2 has
been strongly deprecated since the beginning of 2020, it is best avoided in
any case.
venv is used as a command with python -m venv <directory>,
as there is no dedicated entrypoint. It creates the directory for the
environment.
It is best if this directory does not exist before that. A best practice is to
remove it before creating the environment. There are also two options for
creating the environment: which interpreter to use and what initial
packages to install.
2.2 pip
The packaging tool for Python is pip. There have been other tools that
have mostly been abandoned by the community and should not be used.
Installations of Python used to not come with pip out of the box. This
has changed in recent versions, but many versions which are still
supported do not have it. When running on such a version, python -m
ensurepip installs it.
Some Python installations, especially system ones, disable ensurepip.
When lacking ensurepip, there is a way of manually getting it: get-
pip.py. This is a single downloadable file that, when executed, unpacks
pip.
Luckily, pip is the only package that needs these weird gyrations to
install. All other packages can, and should, be installed using pip.
For example, if sample-environment is a virtual environment,
installing the glom package can be done with the following code.

$ ./sample-environment/bin/python -m pip install glom

...
$ ./sample-environment/bin/python -m glom
{}

The last command tests that glom has been properly installed. Glom is
a package to handle deeply-nested data, and called with no arguments,
outputs an empty Python dictionary. This makes it handy for quickly
testing whether a new virtual environment can install new packages
properly.
Internally, pip is also treated as a third-party package. Upgrading pip
itself is done with pip install --upgrade pip.
Depending on how Python was installed, its real environment might or
might not be modifiable by the user. Many instructions in various README
files and blogs might encourage using sudo pip install. This is
almost always the wrong thing to do; it installs the packages in the global
environment.
The pip install command downloads and installs all dependencies.
However, it can fail to downgrade incompatible packages. It is always
possible to install explicit versions: pip install package-name==
<version> installs this precise version. This is also a good way for local
testing to get explicitly non-general-availability packages, such as release
candidates, beta, or similar.
If wheel is installed, pip builds, and usually caches, wheels for
packages. This is especially useful when dealing with a high virtual
environment churn since installing a cached wheel is a fast operation. This
is also highly useful when dealing with native or binary packages that need
to be compiled with a C compiler. A wheel cache eliminates the need to
build it again.
pip does allow uninstalling with pip uninstall <package>. This
command, by default, requires manual confirmation. Except for exotic
circumstances, this command is not used. If an unintended package has
snuck in, the usual response is to destroy the environment and rebuild it.
For similar reasons, pip install --upgrade <package> is not
often needed; the common response is to destroy and re-create the
environment. There is one situation where it is a good idea.
pip install supports a requirements file: pip install --
requirements or pip install -r. The requirements file simply has
one package per line. This is no different from specifying packages on the
command line. However, requirement files often specify strict
dependencies. A requirements file can be generated from an environment
with pip freeze.
Like most individual packages or wheels, installing anything that is not
strict and closed under requirements requires pip to decide which
dependencies to install. The general problem of dependency resolution
does not have an efficient and complete solution. Different strategies are
possible to approach such a solution.
The way pip resolves dependencies is by using backtracking. This
means that it optimistically tries to download the latest possible
requirements recursively. If a dependency conflict is found, it backtracks;
try a different option.
As an example, consider three packages.
top
middle
base
There are two base versions: 1.0 and 2.0. The package dependencies
are setup.cfg files.
 The following is for the top.

[metadata]
name = top
version = 1.0
[options]
install_requires =
base
middle

The following is for the middle.

[metadata]
name = middle
version = 1.0
[options]
install_requires =
base<2.0

The base package has two versions: 1.0 and 2.0. It does not have any
dependencies.
Because top depends directly on base, pre-backtracking versions of
pip get the latest and then have a failed resolution.

$ pip install top

Looking in links: .
Collecting top
Collecting middle (from top)
Collecting base (from top)
middle 1.0 has requirement base<2.0, but you'll have
base 2.0 which is incompatible.
Installing collected packages: base, middle, top
Successfully installed base-2.0 middle-1.0 top-1.0

The backtracking algorithm discards the base 2.0 version.

$ pip install top

Looking in links: .
Processing ./top-1.0-py3-none-any.whl
Processing ./base-2.0-py3-none-any.whl
Processing ./middle-1.0-py3-none-any.whl
Processing ./base-1.0-py3-none-any.whl
Installing collected packages: base, middle, top
Successfully installed base-1.0 middle-1.0 top-1.0
This solution has the advantage that it is complete, but it can take
unfeasible amounts of time in certain cases. This is rare, but merely taking
a long time is not.
One way to increase the speed is to include >= dependencies in the
loose requirements. This is usually a good idea since packages are better at
guaranteeing backward compatibility than forward compatibility. As a side
benefit, this can dramatically reduce the solution space that pip needs to
backtrack in.
In most scenarios, it is better to use strict requirements for day-to-day
development and regenerate the strict requirements from the loose
requirements (which can take a while) on a cadence that balances keeping
up to date with churn.
2.3 Setup and Wheels
The term third party (as in third-party packages) refers to someone other
than the Python core developers (first-party) or the local developers
(second-party). I have covered how to install first-party packages in the
installation section. You used pip and virtualenv to install third-party
packages. It is time to finally turn your attention to the missing link: local
development and installing local packages or second-party packages.
Note that the word package here means something different from post-
installation. In Python, a package is an importable directory, a way to keep
multiple modules together. The pedantic way to call installable things is
distribution. A distribution can correspond to no packages (it can be a top-
level single-module distribution) or multiple packages.
It is good to keep a 1-1-1 relationship when packaging things: a single
distribution corresponding to one package and named the same. Even if
there is only one file, put it as an __init__.py file under a directory.
Packaging is an area that has seen a lot of changes. Copying and pasting
from existing packages is not a good idea; good packages are, for the most
part, mature packages. Following the latest best practices means making
changes to an existing working process.
Starting with setuptools version 61.0.0, it is possible to create a
package with only two files besides the code files.
pyproject.toml
README.rst
The README is not strictly necessary. However, most source code
management systems display it rendered, so it is best to break it out into its
own file.
Even an empty pyproject.toml generates a package. However,
almost all packages need at least a few more details.
The build-system is the one mandatory section in a non-empty
pyproject.toml file. It is usually the first.

[build-system]
requires = [
"setuptools"
]
build-backend = "setuptools.build_meta"
 Many systems can be used to build valid distributions. The
setuptools system, which used to be the only possibility, is now one of
several. However, it is still the most popular one.
Most of the rest of the data can be found in the project section.

[project]
name = "awesome_package"
version = "0.0.3"
description = "A pretty awesome package"
readme = "README.rst"
authors = [{name = "My Name",
email = "[email protected]"}]
dependencies = ["httpx"]

For most popular code organizations, this is enough for the

setuptools systems to find the code and create a correct package.
There are ways to have setuptools treat the version as dynamic and
take it from a file or an attribute. An alternative is to take advantage of
pyproject.toml in a structured format and manipulate it directly.
For example, the following code uses a CalVer (calendar versioning)
scheme of YEAR.MONTH.release in a month. It uses the built-in
zoneinfo module, which requires Python 3.9 or above, and the tomlkit
library, which supports roundtrip-preserving TOML parsing and
serialization.

import tomlkit
import datetime
import os
import pathlib
import zoneinfo

now =
datetime.datetime.now(tz=zoneinfo.ZoneInfo("UTC"))
prefix=f"{now.year}.{now.month}."
pyproject = pathlib.Path("pyproject.toml")
data = tomlkit.loads(pyproject.read_text())
current = data["project"].get("version", "")
if current.startswith(prefix):
serial = int(current.split(".")[-1]) + 1
else:
serial = 0
version = prefix + str(serial)
data["project"]["version"] = version
pyproject.write_text(tomlkit.dumps(data))
Some utilities keep the version synchronized between several files; for
example, pyproject.toml and example_package/__init__.py.
The best way to use these utilities is by not needing to do it.
If example_package/__init__.py wants to expose the version
number, the best way is to calculate it using importlib.metadata.

# example_package/__init__.py
from importlib import metada
__version__ =
metadata.distribution("example_package").version
del metadata # Keep top-level namespace clean

This avoids needing to keep more than one place in sync.

The field dependencies in pyproject.toml is present on almost
every package. This is how to mark other distributions that the code needs.
It is a good practice to put loose dependencies in pyproject.toml. This
is in contrast to exact dependencies, which specify a specific version. A
loose dependency looks like Twisted>=17.5, specifying a minimum
version but no maximum. Exact dependencies, like Twisted==18.1, are
usually a bad idea in pyproject. toml. They should only be used in
rare cases, for example, when using significant chunks of a private API
package.
The pyproject.toml file also allows defining entrypoints. Some
frameworks, like Pyramid, allow using entrypoints to add plugin-like
features.
It also allows you to define scripts. These used to be
console_scripts entrypoints but now have their own section.

[project.scripts]
example-command = "example_package.commands:main"

The syntax is package.....module:function. This function is

called with no arguments when the script is being run.
 Usually, this includes command-line parsing, but the following is a short
example.

# example_package/commands.py
def main():
print("an example")

In this example, running example-command causes the string to

print.

$ example-command
an example

You can build a distribution with pyproject.toml, a README.rst,

and some Python code. There are several formats a distribution can take,
but the one covered here is the wheel.
After installing build using pip install build, run

python -m build --wheel

This creates a wheel under dist. If the wheel needs to be in a different

directory, add --outdir <output directory> to the command.
You can do several things with the wheel, but it is important to note that
one thing you can do is pip install <wheel file>. Doing this as
part of continuous integration makes sure the wheel, as built by the current
directory, is functional.
It is possible to use python -m build to create a source distribution.
This is usually a good idea to accommodate use cases that prefer to install
from source. These use cases are esoteric, but generating the source
distribution is easy enough to be worth it.

$ python -m build --sdist

It is possible to combine the --sdist and --wheel arguments into

one run of python -m build. This is also what python -m build
does by default: create both a source distribution and a wheel.
By default, python -m build installs any packages it needs to build
the package in a fresh virtual environment. When running python -m
build in a tight edit-debug loop, perhaps to debug a setup.cfg, this can
get tedious. In those cases, create and activate a virtual environment, and
then run

$ python -m build --no-isolation

This installs its dependencies in the current environment. While this is
not a good fit for production use, this is a faster way to debug packaging
issues.
Discovering Diverse Content Through
Random Scribd Documents
tilaisuudessa tuntenut jonkin hipaisevan sääriänsä, ikäänkuin olisi
sormin koetettu saada niistä kiinni. Mutta se oli otaksuttavasti vain
päihtymyksestä johtunutta kouhottelemista, sillä hälinästä huolimatta
kuuli hän hänen naureskelevan hyvin äänekkäästi, ja tarpeettoman
kovilla vasaraniskuilla ja liikanaisella kolinalla ruhjovan hiiliä ja
käsittelevän lapiota. Tämän tästä avasi hän luukun ja heitti ristikon
päälle suunnattoman paljon polttoainetta.

— Jo riittää, kirkasi Jacques.

Toinen ei ollut ymmärtävinään, vaan heitti pesään lapiollisen

toisensa jälkeen. Kun veturinkuljettaja tarttui hänen käsivarteensa,
kääntyi hän uhkaavasti ympäri. Nyt oli hän vihdoinkin saanut
tekosyyn niin kauvan etsimäänsä riitaan ja juovuksissa ollen hän kävi
yhä raivostuneemmaksi.

— Älkää koskeko minuun, taikka minä isken!… Minua huvittaa ajaa

lujaa.

Nyt vieri juna täyttä vauhtia Bolbecin ja Mottevillen välistä

tasankoa. Sen oli mentävä suoraapäätä kohden Pariisia,
pysähtymättä muuta kuin ottamaan vettä eräistä määrätyistä
paikoista. Tuo kahdeksantoista vaunun mahtava jono, joka oli
ahdettu täyteen ihmiskarjaa, vieri myllertäen noiden pimeiden
nummien lomitse. Ja nämä miehet, joita kuljetettiin teurastettavaksi,
roinasivat täyttä kurkkua, niin että se voitti pyörien kolinan.

Jacques sulki luukun jalallansa. Hän voi vielä hillitä itseänsä ja

sanoi:

— On liikaa lämmintä!… Nukahtakaa, jos olette humalassa.

 Pecqueux avasi taas kohta, lisäsi itsepintaisesti hiiliä, ikäänkuin
olisi tahtonut räjähyttää höyrypannun. Se oli niin puhdasta
niskoittelua ja tottelemattomuutta annettuja käskyjä vastaan ja
intohimoisessa suuttumuksessaan ei hän enään ajatellut kaikkien
näiden ihmishenkien turvallisuutta. Kun Jacques kumartui alas
alentaakseen tuhkasäiliön vartta, saadakseen ainakin vähemmän
vetoa, tarttui lämmittäjä häntä kiivaasti vyötäreihin ja koetti työntää
hänet alas radalle.

— Vai niin, senkin veitikka, sitäkö sinä tahdoit!… Sinä luulit voivasi
sanoa minun pudonneen, senkin salakavala lurjus!

Hän oli tarttunut tenderin toiseen syrjään. Molemmat liukuivat ulos

ja tappelua jatkettiin tuolla pienellä, ankarasti tärisevällä peltisillalla.
He purivat hampaansa yhteen, eivät puhuneet sanaakaan ja
koettivat työntää toisensa alas tuosta ahtaasta aukosta, jota
ainoastaan rautatanko oli sulkemassa. Mutta se ei käynyt niinkään
helposti, tuo ahne veturi yhäti vieri vierimistään. Kuljettiin Barentinin
ohi ja juna mennä kohahti Malaunay-tunneliin ja he pitivät
edelleenkin kiinni toisistaan, kieritteleivät hiilien seassa, puskien
päänsä vesisäiliötä vastaan ja väistäen hehkuvanpunaista
tulisijanluukkua, jossa heidän jalkansa voivat paistua, joka kerta kun
he ojensivat ne suoriksi.

Jacques ajatteli silmänräpäyksen, että hän mahdollisesti voisi

saada juostuksi ylös, suljetuksi järjestimen ja huudetuksi apua, jotta
hänet voitaisiin vapauttaa tästä rajusta mielipuolesta, jonka
päihtymys ja mustasukkaisuus saivat raivoamaan. Hän oli pienempi
ja tunsi voimiensa vähenevän. Hän ei toivonut nyt olevansa kylliksi
voimakas syöksemään toista alas, hän tunsi jo olevansa voitettu ja
huomasi, kuinka tukka hänen päässään nousi putoamisen kauhusta
pystyyn. Kun hän teki äärimmäisen ponnistuksen ja hapuili kädellään
ympärillensä, ymmärsi toinen Jacquesin aikomuksen, ja jaloillaan
ponnistaen nosti hän hänet ylös kuten lapsen.

— Ah, sinä aijot pysäyttää junan. Sinä olet ottanut minulta

vaimoni.
Mutta nyt olet joutunut käsiini.

Veturi kohisi kohisemistaan, ja juna tuli ulos tunnelista suurella

kolinalla ja jatkoi juoksuaan eteenpäin pimeäin, avarain nummien
lomitse. Malaunayn aseman ohi kuljettiin sellaisella myrskyn
nopeudella, ett'ei alipäällikkö, joka seisoi asemalaiturilla, edes
huomannut noita kahta miestä, jotka parhaillaan ottivat toisiansa
hengiltä, samalla kun heidät vietiin pois salaman nopeudella.

Mutta viimeisellä voimanponnistuksella onnistui Pecqueuxin

vihdoin syöstä Jacques alas, ja kun tämä tunsi tyhjän ilman
takanaan tarrautui hän hämmennyksissään niin kiinni toisen kaulaan,
että veti hänet mukaansa. Silloin kuului kaksi kamalaa parahdusta,
jotka sulautuivat toisiinsa ja häipyivät avaruuteen. Nämä molemmat,
jotka niin kauvan olivat eläneet kuin veljekset, putosivat nyt yhdessä
alas junasta ja vauhti tempasi heidät pyörien väliin ja he tulivat
kamalassa, lujassa syleilyssään samalla kertaa rikkirevityiksi. Heidät
löydettiin sitten kahtena päättömänä ja jalattomana ruumiina, jotka
vielä olivat toisiinsa kietoutuneina, ikäänkuin olisivat koettaneet
tukehduttaa toisensa.

Veturi, joka nyt oli vapautettuna kaikesta johdosta, mennä vohotti

yhä eteenpäin. Vihdoinkin voi tämä jämeä, oikukas olento tyydyttää
nuoruuden rajuuttansa ikäänkuin vielä ajoon tottumaton hevonen,
joka on päässyt vartijaltaan karkuun ja nelistää tiehensä nummelle
päin. Höyrypannussa oli vielä vettä; hiilet, joita vast'ikään oli lisätty,
syttyivät itsestään palamaan, ja lähinnä seuraavan puolen tunnin
kuluessa nousi paine mielettömästi ja nopeus tuli huimaavaksi.
Ylikonduktöörin oli epäilemättä vallannut väsymys ja hän oli vaipunut
uneen. Sotilaat, jotka tulivat yhä enemmän juovuksiin, ollessaan
noin yhteensullottuina, saivat pian hauskuutta tuosta huimaavasta
vauhdista ja roinasivat vielä kovemmin. Salaman nopeudella
kuljettiin Marommen ohi. Nyt ei veturi enään puhaltanut
lähestyessään merkinantotauluja tai kulkiessaan asemien ohi. Se
nelisti suoraan eteenpäin, kuten eläin, joka painaa päänsä alas, ja
syöksyi eteenpäin kaikkien esteiden läpi. Se syöksyi syöksymistään
loppumattomiin saakka, ikäänkuin olisi sen hengityksen kimakka ääni
saanut sen yhä riivatummaksi.

Rouenissa olisi ollut otettava vettä, ja kauhistus jähmetytti

aseman, kun siellä nähtiin savun ja tulen pyörteessä tulevan tämän
hullautuneen junan, tämän veturin, jossa ei ollut veturinkuljettajaa
eikä lämmittäjää, ja nämä eläinvaunut, sullottuina täyteen
sotamiehiä, jotka roinasivat isänmaallisia lauluja. He olivat matkalla
sotaan ja tahtoivat vieläkin nopeammin päästä tuonne Reinin
rannoille. Virkamiehet jäivät seisomaan suut ammollaan ja
huiskuttivat käsivarsiaan. Syntyi heti yleinen kirkuna: ei milloinkaan
voisi tämä irtipäästetty, omiin hoteisiinsa jätetty juna
onnettomuudetta kulkea ohi Sottevillen aseman, jossa tavallisesti
aina tapahtui junajärjestelyjä, ja joka oli täynnä vaunuja ja vetureja,
kuten kaikilla suurilla varastoasemilla. Riennettiin
sähkösanomatoimistoon ja ryhdyttiin valmistaviin toimenpiteisiin, ja
muuan tavarajuna, joka siellä sulki radan, ehdittiin juuri töintuskin
viedä vajaan. Kuultiin jo etäältä irtipäästetyn pedon huohotus. Se oli
syöksynyt niiden kahden tunnelin läpi, jotka olivat Rouenin lähellä, ja
tuli nyt rajusti nelistäen, kuten vastustamaton jättiläisvoima, jota ei
mikään voi ehkäistä. Sottevillen aseman ohitse syöksyttiin ja juna
mennä vohotti eteenpäin kaikkien esteiden lomitse, törmäämättä
mihinkään, ja katosi sen jälkeen uudelleen pimeyteen, johon sen
pauhu vähitellen häipyi.

Mutta nyt olivat kaikki sähkölennätinkoneet pitkin linjaa liikkeellä

ja kaikkien sydämet sykkivät peljästyksestä, kun saapui tieto tuosta
aaveenkaltaisesta junasta, jonka oli nähty kulkevan Rouenin ja
Sottevillen ohitse. Vavistiin pelosta, että eräs edelläpäin oleva
pikajuna saavutettaisiin. Niin kuin villisika suuressa metsässä, jatkoi
juna juoksuansa, välittämättä kerrassaan mistään
pysähdysmerkeistä. Ei paljon puuttunut, ett'ei se Oisselissa
törmännyt päivystäjäveturiin ja se säikähytti Pont-de l'Archen, sillä
sen nopeus ei näyttänyt vähenevän. Kadottuaan sinne, mennä kohisi
se jälleen eteenpäin pimeässä yössä, ei tiedetty mihin.

Mitäpä välitti se niistä uhreista, jotka se ruhjoi matkallansa! Eikö

se kuitenkin mennyt kohti tulevaisuutta, huoletonna vuodatetusta
verestä? Kuljettajatta yön pimeydessä, kuten sokea ja kuuro eläin,
joka on päästetty irti kuolemaan ja turmioon, mennä kohisi se
eteenpäin, täyteen kuormitettuna tuolla kanuunanruoalla, noilla
väsymyksen jo tylsistyttämillä sotamiehillä.

Loppu.
 *** END OF THE PROJECT GUTENBERG EBOOK IHMISPETO:
SIVEYSROMAANI ***

Updated editions will replace the previous one—the old editions will
be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the free

distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only be

used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.

1.E. Unless you have removed all references to Project Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:
 This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is derived

from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is posted

with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute this

electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the Project
Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or providing

access to or distributing Project Gutenberg™ electronic works
provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
 about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™

electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or
damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for

the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.

1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,

the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will
remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.

The Foundation’s business office is located at 809 North 1500 West,

Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many
small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws regulating

charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states where

we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot make

any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.

Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.
Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.