You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


Navigation

This document describes the Python Distribution Utilities (“Distutils”) from the
end-user’s point-of-view, describing how to extend the capabilities of a
standard Python installation by building and installing third-party Python
modules and extensions.

Note

This guide only covers the basic tools for installing extensions that are
provided as part of this version of Python. Third party tools offer easier
to use and more secure alternatives. Refer to the
quick recommendations section
in the Python Packaging User Guide for more information.

Although Python’s extensive standard library covers many programming needs,
there often comes a time when you need to add some new functionality to your
Python installation in the form of third-party modules. This might be necessary
to support your own programming, or to support an application that you want to
use and that happens to be written in Python.

In the past, there has been little support for adding third-party modules to an
existing Python installation. With the introduction of the Python Distribution
Utilities (Distutils for short) in Python 2.0, this changed.

This document is aimed primarily at the people who need to install third-party
Python modules: end-users and system administrators who just need to get some
Python application running, and existing Python programmers who want to add some
new goodies to their toolbox. You don’t need to know Python to read this
document; there will be some brief forays into using Python’s interactive mode
to explore your installation, but that’s it. If you’re looking for information
on how to distribute your own Python modules so that others may use them, see
the Distributing Python Modules manual. Debugging the setup script may also be of
interest.

In the best case, someone will have prepared a special version of the module
distribution you want to install that is targeted specifically at your platform
and is installed just like any other software on your platform. For example,
the module developer might make an executable installer available for Windows
users, an RPM package for users of RPM-based Linux systems (Red Hat, SuSE,
Mandrake, and many others), a Debian package for users of Debian-based Linux
systems, and so forth.

In that case, you would download the installer appropriate to your platform and
do the obvious thing with it: run it if it’s an executable installer, rpm--install it if it’s an RPM, etc. You don’t need to run Python or a setup
script, you don’t need to compile anything—you might not even need to read any
instructions (although it’s always a good idea to do so anyway).

Of course, things will not always be that easy. You might be interested in a
module distribution that doesn’t have an easy-to-use installer for your
platform. In that case, you’ll have to start with the source distribution
released by the module’s author/maintainer. Installing from a source
distribution is not too hard, as long as the modules are packaged in the
standard way. The bulk of this document is about building and installing
modules from standard source distributions.

If you download a module source distribution, you can tell pretty quickly if it
was packaged and distributed in the standard way, i.e. using the Distutils.
First, the distribution’s name and version number will be featured prominently
in the name of the downloaded archive, e.g. foo-1.0.tar.gz or
widget-0.9.7.zip. Next, the archive will unpack into a similarly-named
directory: foo-1.0 or widget-0.9.7. Additionally, the
distribution will contain a setup script setup.py, and a file named
README.txt or possibly just README, which should explain that
building and installing the module distribution is a simple matter of running
one command from a terminal:

python setup.py install

For Windows, this command should be run from a command prompt window
(Start ‣ Accessories):

setup.py install

If all these things are true, then you already know how to build and install the
modules you’ve just downloaded: Run the command above. Unless you need to
install things in a non-standard way or customize the build process, you don’t
really need this manual. Or rather, the above command is everything you need to
get out of this manual.

You should always run the setup command from the distribution root directory,
i.e. the top-level subdirectory that the module source distribution unpacks
into. For example, if you’ve just downloaded a module source distribution
foo-1.0.tar.gz onto a Unix system, the normal thing to do is:

On Windows, you’d probably download foo-1.0.zip. If you downloaded the
archive file to C:\Temp, then it would unpack into
C:\Temp\foo-1.0; you can use either a archive manipulator with a
graphical user interface (such as WinZip) or a command-line tool (such as
unzip or pkunzip) to unpack the archive. Then, open a
command prompt window and run:

Running setup.pyinstall builds and installs all modules in one run. If you
prefer to work incrementally—especially useful if you want to customize the
build process, or if things are going wrong—you can use the setup script to do
one thing at a time. This is particularly helpful when the build and install
will be done by different users—for example, you might want to build a module
distribution and hand it off to a system administrator for installation (or do
it yourself, with super-user privileges).

For example, you can build everything in one step, and then install everything
in a second step, by invoking the setup script twice:

python setup.py build
python setup.py install

If you do this, you will notice that running the install command
first runs the build command, which—in this case—quickly notices
that it has nothing to do, since everything in the build directory is
up-to-date.

You may not need this ability to break things down often if all you do is
install modules downloaded off the ‘net, but it’s very handy for more advanced
tasks. If you get into distributing your own Python modules and extensions,
you’ll run lots of individual Distutils commands on their own.

As implied above, the build command is responsible for putting the
files to install into a build directory. By default, this is build
under the distribution root; if you’re excessively concerned with speed, or want
to keep the source tree pristine, you can change the build directory with the
--build-base option. For example:

python setup.py build --build-base=/path/to/pybuild/foo-1.0

(Or you could do this permanently with a directive in your system or personal
Distutils configuration file; see section Distutils Configuration Files.) Normally, this
isn’t necessary.

The default layout for the build tree is as follows:

--- build/ --- lib/
or
--- build/ --- lib.<plat>/
temp.<plat>/

where <plat> expands to a brief description of the current OS/hardware
platform and Python version. The first form, with just a lib directory,
is used for “pure module distributions”—that is, module distributions that
include only pure Python modules. If a module distribution contains any
extensions (modules written in C/C++), then the second form, with two <plat>
directories, is used. In that case, the temp.plat directory holds
temporary files generated by the compile/link process that don’t actually get
installed. In either case, the lib (or lib.plat) directory
contains all Python modules (pure Python and extensions) that will be installed.

In the future, more directories will be added to handle Python scripts,
documentation, binary executables, and whatever else is needed to handle the job
of installing Python modules and applications.

After the build command runs (whether you run it explicitly, or the
install command does it for you), the work of the install
command is relatively simple: all it has to do is copy everything under
build/lib (or build/lib.plat) to your chosen installation
directory.

If you don’t choose an installation directory—i.e., if you just run setup.pyinstall—then the install command installs to the standard
location for third-party Python modules. This location varies by platform and
by how you built/installed Python itself. On Unix (and Mac OS X, which is also
Unix-based), it also depends on whether the module distribution being installed
is pure Python or contains extensions (“non-pure”):

Platform

Standard installation location

Default value

Notes

Unix (pure)

prefix/lib/pythonX.Y/site-packages

/usr/local/lib/pythonX.Y/site-packages

(1)

Unix (non-pure)

exec-prefix/lib/pythonX.Y/site-packages

/usr/local/lib/pythonX.Y/site-packages

(1)

Windows

prefix\Lib\site-packages

C:\PythonXY\Lib\site-packages

(2)

Notes:

Most Linux distributions include Python as a standard part of the system, so
prefix and exec-prefix are usually both /usr on
Linux. If you build Python yourself on Linux (or any Unix-like system), the
default prefix and exec-prefix are /usr/local.

The default installation directory on Windows was C:\ProgramFiles\Python under Python 1.6a1, 1.5.2, and earlier.

prefix and exec-prefix stand for the directories that Python
is installed to, and where it finds its libraries at run-time. They are always
the same under Windows, and very often the same under Unix and Mac OS X. You
can find out what your Python installation uses for prefix and
exec-prefix by running Python in interactive mode and typing a few
simple commands. Under Unix, just type python at the shell prompt. Under
Windows, choose Start ‣ Programs ‣ Python X.Y ‣
Python (command line). Once the interpreter is started, you type Python code
at the prompt. For example, on my Linux system, I type the three Python
statements shown below, and get the output as shown, to find out my
prefix and exec-prefix:

A few other placeholders are used in this document: X.Y stands for the
version of Python, for example 2.7; distname will be replaced by
the name of the module distribution being installed. Dots and capitalization
are important in the paths; for example, a value that uses python2.7 on UNIX
will typically use Python27 on Windows.

If you don’t want to install modules to the standard location, or if you don’t
have permission to write there, then you need to read about alternate
installations in section Alternate Installation. If you want to customize your
installation directories more heavily, see section Custom Installation on
custom installations.

Often, it is necessary or desirable to install modules to a location other than
the standard location for third-party Python modules. For example, on a Unix
system you might not have permission to write to the standard third-party module
directory. Or you might wish to try out a module before making it a standard
part of your local Python installation. This is especially true when upgrading
a distribution already present: you want to make sure your existing base of
scripts still works with the new version before actually upgrading.

The Distutils install command is designed to make installing module
distributions to an alternate location simple and painless. The basic idea is
that you supply a base directory for the installation, and the
install command picks a set of directories (called an installation
scheme) under this base directory in which to install files. The details
differ across platforms, so read whichever of the following sections applies to
you.

Note that the various alternate installation schemes are mutually exclusive: you
can pass --user, or --home, or --prefix and --exec-prefix, or
--install-base and --install-platbase, but you can’t mix from these
groups.

This scheme is designed to be the most convenient solution for users that don’t
have write permission to the global site-packages directory or don’t want to
install into it. It is enabled with a simple option:

python setup.py install --user

Files will be installed into subdirectories of site.USER_BASE (written
as userbase hereafter). This scheme installs pure Python modules and
extension modules in the same location (also known as site.USER_SITE).
Here are the values for UNIX, including Mac OS X:

Type of file

Installation directory

modules

userbase/lib/pythonX.Y/site-packages

scripts

userbase/bin

data

userbase

C headers

userbase/include/pythonX.Y/distname

And here are the values used on Windows:

Type of file

Installation directory

modules

userbase\PythonXY\site-packages

scripts

userbase\Scripts

data

userbase

C headers

userbase\PythonXY\Include\distname

The advantage of using this scheme compared to the other ones described below is
that the user site-packages directory is under normal conditions always included
in sys.path (see site for more information), which means that
there is no additional step to perform after running the setup.py script
to finalize the installation.

The build_ext command also has a --user option to add
userbase/include to the compiler search path for header files and
userbase/lib to the compiler search path for libraries as well as to
the runtime search path for shared C libraries (rpath).

The idea behind the “home scheme” is that you build and maintain a personal
stash of Python modules. This scheme’s name is derived from the idea of a
“home” directory on Unix, since it’s not unusual for a Unix user to make their
home directory have a layout similar to /usr/ or /usr/local/.
This scheme can be used by anyone, regardless of the operating system they
are installing for.

Installing a new module distribution is as simple as

python setup.py install --home=<dir>

where you can supply any directory you like for the --home option. On
Unix, lazy typists can just type a tilde (~); the install command
will expand this to your home directory:

The “prefix scheme” is useful when you wish to use one Python installation to
perform the build/install (i.e., to run the setup script), but install modules
into the third-party module directory of a different Python installation (or
something that looks like a different Python installation). If this sounds a
trifle unusual, it is—that’s why the user and home schemes come before. However,
there are at least two known cases where the prefix scheme will be useful.

First, consider that many Linux distributions put Python in /usr, rather
than the more traditional /usr/local. This is entirely appropriate,
since in those cases Python is part of “the system” rather than a local add-on.
However, if you are installing Python modules from source, you probably want
them to go in /usr/local/lib/python2.X rather than
/usr/lib/python2.X. This can be done with

/usr/bin/python setup.py install --prefix=/usr/local

Another possibility is a network filesystem where the name used to write to a
remote directory is different from the name used to read it: for example, the
Python interpreter accessed as /usr/local/bin/python might search for
modules in /usr/local/lib/python2.X, but those modules would have to
be installed to, say, /mnt/@server/export/lib/python2.X. This could
be done with

/usr/local/bin/python setup.py install --prefix=/mnt/@server/export

In either case, the --prefix option defines the installation base, and
the --exec-prefix option defines the platform-specific installation
base, which is used for platform-specific files. (Currently, this just means
non-pure module distributions, but could be expanded to C libraries, binary
executables, etc.) If --exec-prefix is not supplied, it defaults to
--prefix. Files are installed as follows:

Type of file

Installation directory

Python modules

prefix/lib/pythonX.Y/site-packages

extension modules

exec-prefix/lib/pythonX.Y/site-packages

scripts

prefix/bin

data

prefix

C headers

prefix/include/pythonX.Y/distname

There is no requirement that --prefix or --exec-prefix
actually point to an alternate Python installation; if the directories listed
above do not already exist, they are created at installation time.

Incidentally, the real reason the prefix scheme is important is simply that a
standard Unix installation uses the prefix scheme, but with --prefix
and --exec-prefix supplied by Python itself as sys.prefix and
sys.exec_prefix. Thus, you might think you’ll never use the prefix scheme,
but every time you run pythonsetup.pyinstall without any other options,
you’re using it.

Note that installing extensions to an alternate Python installation has no
effect on how those extensions are built: in particular, the Python header files
(Python.h and friends) installed with the Python interpreter used to run
the setup script will be used in compiling extensions. It is your
responsibility to ensure that the interpreter used to run extensions installed
in this way is compatible with the interpreter used to build them. The best way
to do this is to ensure that the two interpreters are the same version of Python
(possibly different builds, or possibly copies of the same build). (Of course,
if your --prefix and --exec-prefix don’t even point to an
alternate Python installation, this is immaterial.)

Windows has no concept of a user’s home directory, and since the standard Python
installation under Windows is simpler than under Unix, the --prefix
option has traditionally been used to install additional packages in separate
locations on Windows.

python setup.py install --prefix="\Temp\Python"

to install modules to the \Temp\Python directory on the current drive.

The installation base is defined by the --prefix option; the
--exec-prefix option is not supported under Windows, which means that
pure Python modules and extension modules are installed into the same location.
Files are installed as follows:

Sometimes, the alternate installation schemes described in section
Alternate Installation just don’t do what you want. You might want to tweak just
one or two directories while keeping everything under the same base directory,
or you might want to completely redefine the installation scheme. In either
case, you’re creating a custom installation scheme.

To create a custom installation scheme, you start with one of the alternate
schemes and override some of the installation directories used for the various
types of files, using these options:

Type of file

Override option

Python modules

--install-purelib

extension modules

--install-platlib

all modules

--install-lib

scripts

--install-scripts

data

--install-data

C headers

--install-headers

These override options can be relative, absolute,
or explicitly defined in terms of one of the installation base directories.
(There are two installation base directories, and they are normally the same—
they only differ when you use the Unix “prefix scheme” and supply different
--prefix and --exec-prefix options; using --install-lib will
override values computed or given for --install-purelib and
--install-platlib, and is recommended for schemes that don’t make a
difference between Python and extension modules.)

For example, say you’re installing a module distribution to your home directory
under Unix—but you want scripts to go in ~/scripts rather than
~/bin. As you might expect, you can override this directory with the
--install-scripts option; in this case, it makes most sense to supply
a relative path, which will be interpreted relative to the installation base
directory (your home directory, in this case):

python setup.py install --home=~ --install-scripts=scripts

Another Unix example: suppose your Python installation was built and installed
with a prefix of /usr/local/python, so under a standard installation
scripts will wind up in /usr/local/python/bin. If you want them in
/usr/local/bin instead, you would supply this absolute directory for the
--install-scripts option:

python setup.py install --install-scripts=/usr/local/bin

(This performs an installation using the “prefix scheme,” where the prefix is
whatever your Python interpreter was installed with— /usr/local/python
in this case.)

If you maintain Python on Windows, you might want third-party modules to live in
a subdirectory of prefix, rather than right in prefix
itself. This is almost as easy as customizing the script installation directory
—you just have to remember that there are two types of modules to worry about,
Python and extension modules, which can conveniently be both controlled by one
option:

python setup.py install --install-lib=Site

The specified installation directory is relative to prefix. Of
course, you also have to ensure that this directory is in Python’s module
search path, such as by putting a .pth file in a site directory (see
site). See section Modifying Python’s Search Path to find out how to modify
Python’s search path.

If you want to define an entire installation scheme, you just have to supply all
of the installation directory options. The recommended way to do this is to
supply relative paths; for example, if you want to maintain all Python
module-related files under python in your home directory, and you want a
separate directory for each platform that you use your home directory from, you
might define the following installation scheme:

$PLAT is not (necessarily) an environment variable—it will be expanded by
the Distutils as it parses your command line options, just as it does when
parsing your configuration file(s).

Obviously, specifying the entire installation scheme every time you install a
new module distribution would be very tedious. Thus, you can put these options
into your Distutils config file (see section Distutils Configuration Files):

Note that these two are not equivalent if you supply a different installation
base directory when you run the setup script. For example,

python setup.py install --install-base=/tmp

would install pure modules to /tmp/python/lib in the first case, and
to /tmp/lib in the second case. (For the second case, you probably
want to supply an installation base of /tmp/python.)

You probably noticed the use of $HOME and $PLAT in the sample
configuration file input. These are Distutils configuration variables, which
bear a strong resemblance to environment variables. In fact, you can use
environment variables in config files on platforms that have such a notion but
the Distutils additionally define a few extra variables that may not be in your
environment, such as $PLAT. (And of course, on systems that don’t have
environment variables, such as Mac OS 9, the configuration variables supplied by
the Distutils are the only ones you can use.) See section Distutils Configuration Files
for details.

When the Python interpreter executes an import statement, it searches
for both Python code and extension modules along a search path. A default value
for the path is configured into the Python binary when the interpreter is built.
You can determine the path by importing the sys module and printing the
value of sys.path.

The expected convention for locally installed packages is to put them in the
.../site-packages/ directory, but you may want to install Python
modules into some arbitrary directory. For example, your site may have a
convention of keeping all software related to the web server under /www.
Add-on Python modules might then belong in /www/python, and in order to
import them, this directory must be added to sys.path. There are several
different ways to add the directory.

The most convenient way is to add a path configuration file to a directory
that’s already on Python’s path, usually to the .../site-packages/
directory. Path configuration files have an extension of .pth, and each
line must contain a single path that will be appended to sys.path. (Because
the new paths are appended to sys.path, modules in the added directories
will not override standard modules. This means you can’t use this mechanism for
installing fixed versions of standard modules.)

Paths can be absolute or relative, in which case they’re relative to the
directory containing the .pth file. See the documentation of
the site module for more information.

A slightly less convenient way is to edit the site.py file in Python’s
standard library, and modify sys.path. site.py is automatically
imported when the Python interpreter is executed, unless the -S switch
is supplied to suppress this behaviour. So you could simply edit
site.py and add two lines to it:

import sys
sys.path.append('/www/python/')

However, if you reinstall the same major version of Python (perhaps when
upgrading from 2.2 to 2.2.2, for example) site.py will be overwritten by
the stock version. You’d have to remember that it was modified and save a copy
before doing the installation.

There are two environment variables that can modify sys.path.
PYTHONHOME sets an alternate value for the prefix of the Python
installation. For example, if PYTHONHOME is set to /www/python,
the search path will be set to ['','/www/python/lib/pythonX.Y/','/www/python/lib/pythonX.Y/plat-linux2',...].

The PYTHONPATH variable can be set to a list of paths that will be
added to the beginning of sys.path. For example, if PYTHONPATH is
set to /www/python:/opt/py, the search path will begin with
['/www/python','/opt/py']. (Note that directories must exist in order to
be added to sys.path; the site module removes paths that don’t
exist.)

Finally, sys.path is just a regular Python list, so any Python application
can modify it by adding or removing entries.

As mentioned above, you can use Distutils configuration files to record personal
or site preferences for any Distutils options. That is, any option to any
command can be stored in one of two or three (depending on your platform)
configuration files, which will be consulted before the command-line is parsed.
This means that configuration files will override default values, and the
command-line will in turn override configuration files. Furthermore, if
multiple configuration files apply, values from “earlier” files are overridden
by “later” files.

The names and locations of the configuration files vary slightly across
platforms. On Unix and Mac OS X, the three configuration files (in the order
they are processed) are:

Type of file

Location and filename

Notes

system

prefix/lib/pythonver/distutils/distutils.cfg

(1)

personal

$HOME/.pydistutils.cfg

(2)

local

setup.cfg

(3)

And on Windows, the configuration files are:

Type of file

Location and filename

Notes

system

prefix\Lib\distutils\distutils.cfg

(4)

personal

%HOME%\pydistutils.cfg

(5)

local

setup.cfg

(3)

On all platforms, the “personal” file can be temporarily disabled by
passing the –no-user-cfg option.

Notes:

Strictly speaking, the system-wide configuration file lives in the directory
where the Distutils are installed; under Python 1.6 and later on Unix, this is
as shown. For Python 1.5.2, the Distutils will normally be installed to
prefix/lib/python1.5/site-packages/distutils, so the system
configuration file should be put there under Python 1.5.2.

On Unix, if the HOME environment variable is not defined, the user’s
home directory will be determined with the getpwuid() function from the
standard pwd module. This is done by the os.path.expanduser()
function used by Distutils.

I.e., in the current directory (usually the location of the setup script).

(See also note (1).) Under Python 1.6 and later, Python’s default “installation
prefix” is C:\Python, so the system configuration file is normally
C:\Python\Lib\distutils\distutils.cfg. Under Python 1.5.2, the
default prefix was C:\ProgramFiles\Python, and the Distutils were not
part of the standard library—so the system configuration file would be
C:\ProgramFiles\Python\distutils\distutils.cfg in a standard Python
1.5.2 installation under Windows.

On Windows, if the HOME environment variable is not defined,
USERPROFILE then HOMEDRIVE and HOMEPATH will
be tried. This is done by the os.path.expanduser() function used
by Distutils.

The Distutils configuration files all have the same syntax. The config files
are grouped into sections. There is one section for each Distutils command,
plus a global section for global options that affect every command. Each
section consists of one option per line, specified as option=value.

For example, the following is a complete config file that just forces all
commands to run quietly by default:

[global]
verbose=0

If this is installed as the system config file, it will affect all processing of
any Python module distribution by any user on the current system. If it is
installed as your personal config file (on systems that support them), it will
affect only module distributions processed by you. And if it is used as the
setup.cfg for a particular module distribution, it affects only that
distribution.

You could override the default “build base” directory and make the
build* commands always forcibly rebuild all files with the
following:

[build]
build-base=blib
force=1

which corresponds to the command-line arguments

python setup.py build --build-base=blib --force

except that including the build command on the command-line means
that command will be run. Including a particular command in config files has no
such implication; it only means that if the command is run, the options in the
config file will apply. (Or if other commands that derive values from it are
run, they will use the values in the config file.)

You can find out the complete list of options for any command using the
--help option, e.g.:

python setup.py build --help

and you can find out the complete list of global options by using
--help without a command:

python setup.py --help

See also the “Reference” section of the “Distributing Python Modules” manual.

Whenever possible, the Distutils try to use the configuration information made
available by the Python interpreter used to run the setup.py script.
For example, the same compiler and linker flags used to compile Python will also
be used for compiling extensions. Usually this will work well, but in
complicated situations this might be inappropriate. This section discusses how
to override the usual Distutils behaviour.

Compiling a Python extension written in C or C++ will sometimes require
specifying custom flags for the compiler and linker in order to use a particular
library or produce a special kind of object code. This is especially true if the
extension hasn’t been tested on your platform, or if you’re trying to
cross-compile Python.

In the most general case, the extension author might have foreseen that
compiling the extensions would be complicated, and provided a Setup file
for you to edit. This will likely only be done if the module distribution
contains many separate extension modules, or if they often require elaborate
sets of compiler flags in order to work.

A Setup file, if present, is parsed in order to get a list of extensions
to build. Each line in a Setup describes a single module. Lines have
the following structure:

module ... [sourcefile ...] [cpparg ...] [library ...]

Let’s examine each of the fields in turn.

module is the name of the extension module to be built, and should be a
valid Python identifier. You can’t just change this in order to rename a module
(edits to the source code would also be needed), so this should be left alone.

sourcefile is anything that’s likely to be a source code file, at least
judging by the filename. Filenames ending in .c are assumed to be
written in C, filenames ending in .C, .cc, and .c++ are
assumed to be C++, and filenames ending in .m or .mm are assumed
to be in Objective C.

cpparg is an argument for the C preprocessor, and is anything starting with
-I, -D, -U or -C.

library is anything ending in .a or beginning with -l or
-L.

If a particular platform requires a special library on your platform, you can
add it by editing the Setup file and running pythonsetup.pybuild.
For example, if the module defined by the line

foo foomodule.c

must be linked with the math library libm.a on your platform, simply add
-lm to the line:

foo foomodule.c -lm

Arbitrary switches intended for the compiler or the linker can be supplied with
the -Xcompilerarg and -Xlinkerarg options:

foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm

The next option after -Xcompiler and -Xlinker will be
appended to the proper command line, so in the above example the compiler will
be passed the -o32 option, and the linker will be passed
-shared. If a compiler option requires an argument, you’ll have to
supply multiple -Xcompiler options; for example, to pass -xc++
the Setup file would have to contain -Xcompiler-x-Xcompilerc++.

Compiler flags can also be supplied through setting the CFLAGS
environment variable. If set, the contents of CFLAGS will be added to
the compiler flags specified in the Setup file.

This subsection describes the necessary steps to use Distutils with the Borland
C++ compiler version 5.5. First you have to know that Borland’s object file
format (OMF) is different from the format used by the Python version you can
download from the Python or ActiveState Web site. (Python is built with
Microsoft Visual C++, which uses COFF as the object file format.) For this
reason you have to convert Python’s library python25.lib into the
Borland format. You can do this as follows:

coff2omf python25.lib python25_bcpp.lib

The coff2omf program comes with the Borland compiler. The file
python25.lib is in the Libs directory of your Python
installation. If your extension uses other libraries (zlib, ...) you have to
convert them too.

The converted files have to reside in the same directories as the normal
libraries.

How does Distutils manage to use these libraries with their changed names? If
the extension needs a library (eg. foo) Distutils checks first if it
finds a library with suffix _bcpp (eg. foo_bcpp.lib) and then
uses this library. In the case it doesn’t find such a special library it uses
the default name (foo.lib.) [1]

To let Distutils compile your extension with Borland C++ you now have to type:

python setup.py build --compiler=bcpp

If you want to use the Borland C++ compiler as the default, you could specify
this in your personal or system-wide configuration file for Distutils (see
section Distutils Configuration Files.)

This section describes the necessary steps to use Distutils with the GNU C/C++
compilers in their Cygwin and MinGW distributions. [2] For a Python interpreter
that was built with Cygwin, everything should work without any of these
following steps.

Not all extensions can be built with MinGW or Cygwin, but many can. Extensions
most likely to not work are those that use C++ or depend on Microsoft Visual C
extensions.

If you want to use any of these options/compilers as default, you should
consider writing it in your personal or system-wide configuration file for
Distutils (see section Distutils Configuration Files.)

The location of an installed python25.dll will depend on the
installation options and the version and language of Windows. In a “just for
me” installation, it will appear in the root of the installation directory. In
a shared installation, it will be located in the system directory.