In the most simple case,
set the current directory to the location of your program myscript.py
and execute:

pyinstaller myscript.py

PyInstaller analyzes myscript.py and:

Writes myscript.spec in the same folder as the script.

Creates a folder build in the same folder as the script if it does not exist.

Writes some log files and working files in the build folder.

Creates a folder dist in the same folder as the script if it does not exist.

Writes the myscript executable folder in the dist folder.

In the dist folder you find the bundled app you distribute to your users.

Normally you name one script on the command line.
If you name more, all are analyzed and included in the output.
However, the first script named supplies the name for the
spec file and for the executable folder or file.
Its code is the first to execute at run-time.

For certain uses you may edit the contents of myscript.spec
(described under Using Spec Files).
After you do this, you name the spec file to PyInstaller instead of the script:

A path to search for imports (like using PYTHONPATH).
Multiple paths are allowed, separated by ‘:’, or use
this option multiple times

--hidden-import MODULENAME, --hiddenimport MODULENAME

Name an import not visible in the code of the
script(s). This option can be used multiple times.

--additional-hooks-dir HOOKSPATH

An additional path to search for hooks. This option
can be used multiple times.

--runtime-hook RUNTIME_HOOKS

Path to a custom runtime hook file. A runtime hook is
code that is bundled with the executable and is
executed before any other code or module to set up
special features of the runtime environment. This
option can be used multiple times.

--exclude-module EXCLUDES

Optional module or package (his Python names, not path
names) that will be ignored (as though it was not
found). This option can be used multiple times.

Add or update a resource to a Windows executable. The
RESOURCE is one to four items,
FILE[,TYPE[,NAME[,LANGUAGE]]]. FILE can be a data file
or an exe/dll. For data files, at least TYPE and NAME
must be specified. LANGUAGE defaults to 0 or may be
specified as wildcard * to update all resources of the
given TYPE and NAME. For exe/dll files, all resources
from FILE will be added/updated to the final
executable if TYPE, NAME and LANGUAGE are omitted or
specified as wildcard *.This option can be used
multiple times.

--uac-admin

Using this option creates a Manifest which will
request elevation upon application restart.

--uac-uiaccess

Using this option allows an elevated application to
work with Remote Desktop.

Any Shared Assemblies bundled into the application
will be changed into Private Assemblies. This means
the exact versions of these assemblies will always be
used, and any newer versions installed on user
machines at the system level will be ignored.

--win-no-prefer-redirects

While searching for Shared or Private Assemblies to
bundle into the application, PyInstaller will prefer
not to follow policies that redirect to newer
versions, and will try to bundle the exact versions of
the assembly.

Mac OS X .app bundle identifier is used as the default
unique program name for code signing purposes. The
usual form is a hierarchical name in reverse DNS
notation. For example:
com.mycompany.department.appname (default: first
script’s basename)

Because of its numerous options, a full pyinstaller command
can become very long.
You will run the same command again and again as you develop
your script.
You can put the command in a shell script or batch file,
using line continuations to make it readable.
For example, in Linux:

UPX is a free utility available for most operating systems.
UPX compresses executable files and libraries, making them smaller,
sometimes much smaller.
UPX is available for most operating systems and can compress
a large number of executable file formats.
See the UPX home page for downloads, and for the list of
supported executable formats.
Development of UPX appears to have ended in September 2013,
at which time it supported most executable formats except for
64-bit binaries for Mac OS X.
UPX has no effect on those.

A compressed executable program is wrapped in UPX
startup code that dynamically decompresses the program
when the program is launched.
After it has been decompressed, the program runs normally.
In the case of a PyInstaller one-file executable that has
been UPX-compressed, the full execution sequence is:

The compressed program start up in the UPX decompressor code.

After decompression, the program executes the PyInstaller bootloader,
which creates a temporary environment for Python.

The Python interpreter executes your script.

PyInstaller looks for UPX on the execution path
or the path specified with the --upx-dir option.
If UPX exists, PyInstaller applies it to the final executable,
unless the --noupx option was given.
UPX has been used with PyInstaller output often, usually with no problems.

To encrypt the Python bytecode modules stored in the bundle,
pass the --key=key-string argument on
the command line.

For this to work, you must have the PyCrypto
module installed.
The key-string is a string of 16 characters which is used to
encrypt each file of Python byte-code before it is stored in
the archive inside the executable file.

When you need to bundle your application within one OS
but for different versions of Python and support libraries – for example,
a Python 3 version and a Python 2.7 version;
or a supported version that uses Qt4 and a development version that uses Qt5 –
we recommend you use virtualenv.
With virtualenv you can maintain different combinations of Python
and installed packages, and switch from one combination to another easily.
(If you work only with Python 3.4 and later, the built-in script pyvenv
does the same job.)

Use virtualenv to create as many different development environments as you need,
each with its unique combination of Python and installed packages.

Install PyInstaller in each environment.

Use PyInstaller to build your application in each environment.

Note that when using virtualenv, the path to the PyInstaller commands is:

Windows: ENV_ROOT\Scripts

Others: ENV_ROOT/bin

Under Windows, the pip-Win package installs virtualenv and makes it
especially easy to set up different environments and switch between them.
Under Linux and Mac OS, you switch environments at the command line.

If you need to distribute your application for more than one OS,
for example both Windows and Mac OS X, you must install PyInstaller
on each platform and bundle your app separately on each.

You can do this from a single machine using virtualization.
The free virtualBox or the paid VMWare and Parallels
allow you to run another complete operating system as a “guest”.
You set up a virtual machine for each “guest” OS.
In it you install
Python, the support packages your application needs, and PyInstaller.

The Dropbox system is useful with virtual machines.
Install a Dropbox client in each virtual machine, all linked to your Dropbox account.
Keep a single copy of your script(s) in a Dropbox folder.
Then on any virtual machine you can run PyInstaller thus:

PyInstaller reads scripts from the common Dropbox folder,
but writes its work files and the bundled app in folders that
are local to the virtual machine.

If you share the same home directory on multiple platforms, for
example Linux and OS X, you will need to set the PYINSTALLER_CONFIG_DIR
environment variable to different values on each platform otherwise
PyInstaller may cache files for one platform and use them on the other
platform, as by default it uses a subdirectory of your home directory
as its cache location.

It is said to be possible to cross-develop for Windows under Linux
using the free Wine environment.
Further details are needed, see How to Contribute.

Under Linux, PyInstaller does not bundle libc
(the C standard library, usually glibc, the Gnu version) with the app.
Instead, the app expects to link dynamically to the libc from the
local OS where it runs.
The interface between any app and libc is forward compatible to
newer releases, but it is not backward compatible to older releases.

For this reason, if you bundle your app on the current version of Linux,
it may fail to execute (typically with a runtime dynamic link error) if
it is executed on an older version of Linux.

The solution is to always build your app on the oldest version of
Linux you mean to support.
It should continue to work with the libc found on newer versions.

The Linux standard libraries such as glibc are distributed in 64-bit
and 32-bit versions, and these are not compatible.
As a result you cannot bundle your app on a 32-bit system and run it
on a 64-bit installation, nor vice-versa.
You must make a unique version of the app for each word-length supported.

A Windows app may require a Version resource file.
A Version resource contains a group of data structures,
some containing binary integers and some containing strings,
that describe the properties of the executable.
For details see the Microsoft Version Information Structures page.

Version resources are complex and
some elements are optional, others required.
When you view the version tab of a Properties dialog,
there’s no simple relationship between
the data displayed and the structure of the resource.
For this reason PyInstaller includes the pyi-grab_version command.
It is invoked with the full path name of any Windows executable
that has a Version resource:

pyi-grab_versionexecutable_with_version_resource

The command writes text that represents
a Version resource in readable form to standard output.
You can copy it from the console window or redirect it to a file.
Then you can edit the version information to adapt it to your program.
Using pyi-grab_version you can find an executable that displays the kind of
information you want, copy its resource data, and modify it to suit your package.

The version text file is encoded UTF-8 and may contain non-ASCII characters.
(Unicode characters are allowed in Version resource string fields.)
Be sure to edit and save the text file in UTF-8 unless you are
certain it contains only ASCII string values.

Your edited version text file can be given with the --version-file=
option to pyinstaller or pyi-makespec.
The text data is converted to a Version resource and
installed in the bundled app.

In a Version resource there are two 64-bit binary values,
FileVersion and ProductVersion.
In the version text file these are given as four-element tuples,
for example:

filevers=(2,0,4,0),prodvers=(2,0,4,0),

The elements of each tuple represent 16-bit values
from most-significant to least-significant.
For example the value (2,0,4,0) resolves to
0002000000040000 in hex.

You can also install a Version resource from a text file after
the bundled app has been created, using the set_version command:

set_versionversion_text_fileexecutable_file

The set_version utility reads a version text file as written
by pyi-grab_version, converts it to a Version resource,
and installs that resource in the executable_file specified.

For advanced uses, examine a version text file as written by pyi-grab_version.
You find it is Python code that creates a VSVersionInfo object.
The class definition for VSVersionInfo is found in
utils/win32/versioninfo.py in the PyInstaller distribution folder.
You can write a program that imports versioninfo.
In that program you can eval
the contents of a version info text file to produce a
VSVersionInfo object.
You can use the .toRaw() method of that object to
produce a Version resource in binary form.
Or you can apply the unicode() function to the object
to reproduce the version text file.

If you specify only --onefile under Mac OS X, the output
in dist is a UNIX executable
myscript.
It can be executed from a Terminal command line.
Standard input and output work as normal through the Terminal window.

If you also specify --windowed, the dist folder contains
two outputs: the UNIX executable myscript
and also an OS X application named myscript.app.

As you probably know, an application is a special type of folder.
The one built by PyInstaller contains a folder always named Contents.
It contains:

A folder Frameworks which is empty.

A folder MacOS that contains a copy of the same myscript UNIX executable.

In Mac OS X, components from one version of the OS are usually compatible
with later versions, but they may not work with earlier versions.

The only way to be certain your app supports an older version of Mac OS X
is to run PyInstaller in the oldest version of the OS you need to support.

For example, to be sure of compatibility with “Snow Leopard” (10.6)
and later versions, you should execute PyInstaller in that environment.
You would create a copy of Mac OS X 10.6, typically in a virtual machine.
In it, install the desired level of Python
(the default Python in Snow Leopard was 2.6, which PyInstaller no longer supports),
and install PyInstaller, your source, and all its dependencies.
Then build your app in that environment.
It should be compatible with later versions of Mac OS X.

Older versions of Mac OS X supported both 32-bit and 64-bit executables.
PyInstaller builds an app using the the word-length of the Python used to execute it.
That will typically be a 64-bit version of Python,
resulting in a 64-bit executable.
To create a 32-bit executable, run PyInstaller under a 32-bit Python.

Python as installed in OS X will usually be executable in either 64- or 32-bit mode.
To verify this, apply the file command to the Python executable:

Apple’s default /usr/bin/python may circumvent the arch
specification and run 64-bit regardless.
(That is not the case if you apply arch to a specific version
such as /usr/bin/python2.7.)
To make sure of running 32-bit in all cases, set the following environment variable:

Support for OpenDocument events is broken in PyInstaller 3.0
owing to code changes needed in the bootloader to support current
versions of Mac OS X.
Do not attempt to use this feature until it has been fixed.
If this feature is important to you, follow and comment on
the status of PyInstaller Issue #1309.

When a user double-clicks a document of a type your application
supports, or when a user drags a document icon and drops it
on your application’s icon, Mac OS X launches your application
and provides the name(s) of the opened document(s) in the
form of an OpenDocument AppleEvent.
This AppleEvent is received by the bootloader
before your code has started executing.

The bootloader gets the names of opened documents from
the OpenDocument event and encodes them into the argv
string before starting your code.
Thus your code can query sys.argv to get the names
of documents that should be opened at startup.

OpenDocument is the only AppleEvent the bootloader handles.
If you want to handle other events, or events that
are delivered after the program has launched, you must
set up the appropriate handlers.