Pip install pyinstaller как установить

How to Install PyInstaller¶

PyInstaller is available as a regular Python package. The source archives for released versions are available from PyPi, but it is easier to install the latest version using pip:

To upgrade existing PyInstaller installation to the latest version, use:

To install the current development version, use:

To install directly using pip’s built-in git checkout support, use:

or to install specific branch (e.g., develop ):

Installing from the source archive¶

The source code archive for released versions of PyInstaller are available at PyPI and on PyInstaller Downloads page.

Even though the source archive provides the setup.py script, installation via python setup.py install has been deprecated and should not be used anymore. Instead, run pip install . from the unpacked source directory, as described below.

Unpack the source archive.

Move into the unpacked source directory.

Run pip install . from the unpacked source directory. If installing into system-wide python installation, administrator privilege is required.

The same procedure applies to installing from manual git checkout:

If you intend to make changes to the source code and want them to take effect immediately, without re-installing the package each time, you can install it in editable mode:

For platforms other than Windows, GNU/Linux and macOS, you must first build the bootloader for your platform: see Building the Bootloader . After the bootloader has been built, use the pip install . command to complete the installation.

Verifying the installation¶

On all platforms, the command pyinstaller should now exist on the execution path. To verify this, enter the command:

The result should resemble 4.n for a released version, and 4.n.dev0-xxxxxx for a development branch.

If the command is not found, make sure the execution path includes the proper directory:

Windows: C:\PythonXY\Scripts where XY stands for the major and minor Python version number, for example C:\Python38\Scripts for Python 3.8)

macOS (using the default Apple-supplied Python) /usr/bin

macOS (using Python installed by homebrew) /usr/local/bin

macOS (using Python installed by macports) /opt/local/bin

To display the current path in Windows the command is echo %path% and in other systems, echo $PATH .

If you cannot use the pyinstaller command due to the scripts directory not being in PATH , you can instead invoke the PyInstaller module, by running python -m PyInstaller (pay attention to the module name, which is case sensitive). This form of invocation is also useful when you have PyInstaller installed in multiple python environments, and you cannot be sure from which installation the pyinstaller command will be ran.

Installed commands¶

The complete installation places these commands on the execution path:

pyinstaller is the main command to build a bundled application. See Using PyInstaller .

pyi-makespec is used to create a spec file. See Using Spec Files .

pyi-archive_viewer is used to inspect a bundled application. See Inspecting Archives .

pyi-bindepend is used to display dependencies of an executable. See Inspecting Executables .

pyi-grab_version is used to extract a version resource from a Windows executable. See Capturing Windows Version Data .

pyi-set_version can be used to apply previously-extracted version resource to an existing Windows executable.

© Copyright This document has been placed in the public domain.. Revision 58b8235b .

Как создать exe файл для Python кода с помощью PyInstaller

Установка PyInstaller не отличается от установки любой другой библиотеки Python.

Вот так можно проверить версию PyInstaller.

Я использую PyInstaller версии 4.2.

Создание exe файла с помощью PyInstaller

PyInstaller собирает в один пакет Python-приложение и все необходимые ему библиотеки следующим образом:

1. Считывает файл скрипта.
2. Анализирует код для выявления всех зависимостей, необходимых для работы.
3. Создает файл spec, который содержит название скрипта, библиотеки-зависимости, любые файлы, включая те параметры, которые были переданы в команду PyInstaller.
4. Собирает копии всех библиотек и файлов вместе с активным интерпретатором Python.
5. Создает папку BUILD в папке со скриптом и записывает логи вместе с рабочими файлами в BUILD.
6. Создает папку DIST в папке со скриптом, если она еще не существует.
7. Записывает все необходимые файлы вместе со скриптом или в одну папку, или в один исполняемый файл.

Если использовать параметр команды onedir или -D при генерации исполняемого файла, тогда все будет помещено в одну папку. Это поведение по умолчанию. Если же использовать параметр onefile или -F , то все окажется в одном исполняемом файле.

Возьмем в качестве примера простейший скрипт на Python c названием simple.py, который содержит такой код.

Создадим один исполняемый файл. В командной строке введите:

После завершения установки будет две папки, BUILD и DIST, а также новый файл с расширением .spec. Spec-файл будет называться так же, как и файл скрипта.

Python создает каталог распространения, который содержит основной исполняемый файл, а также все динамические библиотеки.

Вот что произойдет после запуска файла.

Также, открыв spec-файл, можно увидеть раздел datas, в котором указывается, что файл netflix_titles.csv копируется в текущую директорию.

Запустим файл simple1.exe, появится консоль с выводом: Всего фильмов: 7787 .

Добавление файлов с данными и параметр onefile

Если задать параметр —onefile , то PyInstaller распаковывает все файлы в папку TEMP, выполняет скрипт и удаляет TEMP. Если вместе с add-data указать onefile, то нужно считать данные из папки. Путь папки меняется и похож на «_MEIxxxxxx-folder».

Скрипт обновлен для чтения папки TEMP и файлов с данными. Создадим exe-файл с помощью onefile и add-data.

После успешного создания файл simple1.exe появится в папке DIST.

Можно скопировать исполняемый файл на рабочий стол и запустить, чтобы убедиться, что нет никакой ошибки, связанной с отсутствием файла.

Дополнительные импорты с помощью Hidden Imports

Исполняемому файлу требуются все импорты, которые нужны Python-скрипту. Иногда PyInstaller может пропустить динамические импорты или импорты второго уровня, возвращая ошибку ImportError: No module named …

Для решения этой ошибки нужно передать название недостающей библиотеки в hidden-import.

Например, чтобы добавить библиотеку os, нужно написать вот так:

Файл spec

Файл spec — это первый файл, который PyInstaller создает, чтобы закодировать содержимое скрипта Python вместе с параметрами, переданными при запуске.

PyInstaller считывает содержимое файла для создания исполняемого файла, определяя все, что может понадобиться для него.

Файл с расширением .spec сохраняется по умолчанию в текущей директории.

Если у вас есть какое-либо из нижеперечисленных требований, то вы можете изменить файл спецификации:

• Собрать в один бандл с исполняемым файлы данных.
• Включить другие исполняемые файлы: .dll или .so.
• С помощью библиотек собрать в один бандл несколько программы.

Например, есть скрипт simpleModel.py, который использует TensorFlow и выводит номер версии этой библиотеки.

Компилируем модель с помощью PyInstaller:

После успешной компиляции запускаем исполняемый файл, который возвращает следующую ошибку.

Исправим ее, обновив файл spec. Одно из решений — создать файл spec.

Команда pyi-makespec создает spec-файл по умолчанию, содержащий все параметры, которые можно указать в командной строке. Файл simpleModel.spec создается в текущей директории.

Поскольку был использован параметр —onefile , то внутри файла будет только раздел exe.

Если использовать параметр по умолчанию или onedir, то вместе с exe-разделом будет также и раздел collect.

Можно открыть simpleModel.spec и добавить следующий текст для создания хуков.

Создаем хуки и добавляем их в hidden imports и раздел данных.

Файлы хуков расширяют возможность PyInstaller обрабатывать такие требования, как необходимость включать дополнительные данные или импортировать динамические библиотеки.

Обычно пакеты Python используют нормальные методы для импорта своих зависимостей, но в отдельных случаях, как например TensorFlow, существует необходимость импорта динамических библиотек. PyInstaller не может найти все библиотеки, или же их может быть слишком много. В таком случае рекомендуется использовать вспомогательный инструмент для импорта из PyInstaller.utils.hooks и собрать все подмодули для библиотеки.

Скомпилируем модель после обновления файла simpleModel.spec.

Скопируем исполняемый файл на рабочий стол и увидим, что теперь он корректно отображает версию TensorFlow.

Вывод:

PyInstaller предлагает несколько вариантов создания простых и сложных исполняемых файлов из Python-скриптов:

Using PyInstaller to Easily Distribute Python Applications

Are you jealous of Go developers building an executable and easily shipping it to users? Wouldn’t it be great if your users could run your application without installing anything? That is the dream, and PyInstaller is one way to get there in the Python ecosystem.

There are countless tutorials on how to set up virtual environments, manage dependencies, avoid dependency pitfalls, and publish to PyPI, which is useful when you’re creating Python libraries. There is much less information for developers building Python applications. This tutorial is for developers who want to distribute applications to users who may or may not be Python developers.

In this tutorial, you’ll learn the following:

• How PyInstaller can simplify application distribution
• How to use PyInstaller on your own projects
• How to debug PyInstaller errors
• What PyInstaller can’t do

PyInstaller gives you the ability to create a folder or executable that users can immediately run without any extra installation. To fully appreciate PyInstaller’s power, it’s useful to revisit some of the distribution problems PyInstaller helps you avoid.

Free Bonus: 5 Thoughts On Python Mastery, a free course for Python developers that shows you the roadmap and the mindset you’ll need to take your Python skills to the next level.

Distribution Problems

Setting up a Python project can be frustrating, especially for non-developers. Often, the setup starts with opening a Terminal, which is a non-starter for a huge group of potential users. This roadblock stops users even before the installation guide delves into the complicated details of virtual environments, Python versions, and the myriad of potential dependencies.

Think about what you typically go through when setting up a new machine for Python development. It probably goes something like this:

• Download and install a specific version of Python
• Set up pip
• Set up a virtual environment
• Get a copy of your code
• Install dependencies

Stop for a moment and consider if any of the above steps make any sense if you’re not a developer, let alone a Python developer. Probably not.

These problems explode if your user is lucky enough to get to the dependencies portion of the installation. This has gotten much better in the last few years with the prevalence of wheels, but some dependencies still require C/C++ or even FORTRAN compilers!

This barrier to entry is way too high if your goal is to make an application available to as many users as possible. As Raymond Hettinger often says in his excellent talks, “There has to be a better way.”

PyInstaller

PyInstaller abstracts these details from the user by finding all your dependencies and bundling them together. Your users won’t even know they’re running a Python project because the Python Interpreter itself is bundled into your application. Goodbye complicated installation instructions!

PyInstaller performs this amazing feat by introspecting your Python code, detecting your dependencies, and then packaging them into a suitable format depending on your Operating System.

There are lots of interesting details about PyInstaller, but for now you’ll learn the basics of how it works and how to use it. You can always refer to the excellent PyInstaller docs if you want more details.

In addition, PyInstaller can create executables for Windows, Linux, or macOS. This means Windows users will get a .exe , Linux users get a regular executable, and macOS users get a .app bundle. There are some caveats to this. See the limitations section for more information.

Preparing Your Project

PyInstaller requires your application to conform to some minimal structure, namely that you have a CLI script to start your application. Often, this means creating a small script outside of your Python package that simply imports your package and runs main() .

The entry-point script is a Python script. You can technically do anything you want in the entry-point script, but you should avoid using explicit relative imports. You can still use relative imports throughout the rest your application if that’s your preferred style.

Note: An entry-point is the code that starts your project or application.

You can give this a try with your own project or follow along with the Real Python feed reader project. For more detailed information on the reader project, check out the the tutorial on Publishing a Package on PyPI.

The first step to building an executable version of this project is to add the entry-point script. Luckily, the feed reader project is well structured, so all you need is a short script outside the package to run it. For example, you can create a file called cli.py alongside the reader package with the following code:

This cli.py script calls main() to start up the feed reader.

Creating this entry-point script is straightforward when you’re working on your own project because you’re familiar with the code. However, it’s not as easy to find the entry-point of another person’s code. In this case, you can start by looking at the setup.py file in the third-party project.

Look for a reference to the entry_points argument in the project’s setup.py . For example, here’s the reader project’s setup.py :

As you can see, the entry-point cli.py script calls the same function mentioned in the entry_points argument.

After this change, the reader project directory should look like this, assuming you checked it out into a folder called reader :

Notice there is no change to the reader code itself, just a new file called cli.py . This entry-point script is usually all that’s necessary to use your project with PyInstaller.

However, you’ll also want to look out for uses of __import__() or imports inside of functions. These are referred to as hidden imports in PyInstaller terminology.

You can manually specify the hidden imports to force PyInstaller to include those dependencies if changing the imports in your application is too difficult. You’ll see how to do this later in this tutorial.

Once you can launch your application with a Python script outside of your package, you’re ready to give PyInstaller a try at creating an executable.

Using PyInstaller

The first step is to install PyInstaller from PyPI. You can do this using pip like other Python packages:

pip will install PyInstaller’s dependencies along with a new command: pyinstaller . PyInstaller can be imported in your Python code and used as a library, but you’ll likely only use it as a CLI tool.

You’ll use the library interface if you create your own hook files.

You’ll increase the likelihood of PyInstaller’s defaults creating an executable if you only have pure Python dependencies. However, don’t stress too much if you have more complicated dependencies with C/C++ extensions.

PyInstaller supports lots of popular packages like NumPy, PyQt, and Matplotlib without any additional work from you. You can see more about the list of packages that PyInstaller officially supports by referring to the PyInstaller documentation.

Don’t worry if some of your dependencies aren’t listed in the official docs. Many Python packages work fine. In fact, PyInstaller is popular enough that many projects have explanations on how to get things working with PyInstaller.

In short, the chances of your project working out of the box are high.

To try creating an executable with all the defaults, simply give PyInstaller the name of your main entry-point script.

First, cd in the folder with your entry-point and pass it as an argument to the pyinstaller command that was added to your PATH when PyInstaller was installed.

For example, type the following after you cd into the top-level reader directory if you’re following along with the feed reader project:

Don’t be alarmed if you see a lot of output while building your executable. PyInstaller is verbose by default, and the verbosity can be cranked way up for debugging, which you’ll see later.

Digging Into PyInstaller Artifacts

PyInstaller is complicated under the hood and will create a lot of output. So, it’s important to know what to focus on first. Namely, the executable you can distribute to your users and potential debugging information. By default, the pyinstaller command will create a few things of interest:

• A *.spec file
• A build/ folder
• A dist/ folder

Spec File

The spec file will be named after your CLI script by default. Sticking with our previous example, you’ll see a file called cli.spec . Here’s what the default spec file looks like after running PyInstaller on the cli.py file:

This file will be automatically created by the pyinstaller command. Your version will have different paths, but the majority should be the same.

Don’t worry, you don’t need to understand the above code to effectively use PyInstaller!

This file can be modified and re-used to create executables later. You can make future builds a bit faster by providing this spec file instead of the entry-point script to the pyinstaller command.

There are a few specific use-cases for PyInstaller spec files. However, for simple projects, you won’t need to worry about those details unless you want to heavily customize how your project is built.

Build Folder

The build/ folder is where PyInstaller puts most of the metadata and internal bookkeeping for building your executable. The default contents will look something like this:

The build folder can be useful for debugging, but unless you have problems, this folder can largely be ignored. You’ll learn more about debugging later in this tutorial.

Dist Folder

After building, you’ll end up with a dist/ folder similar to the following:

The dist/ folder contains the final artifact you’ll want to ship to your users. Inside the dist/ folder, there is a folder named after your entry-point. So in this example, you’ll have a dist/cli folder that contains all the dependencies and executable for our application. The executable to run is dist/cli/cli or dist/cli/cli.exe if you’re on Windows.

You’ll also find lots of files with the extension .so , .pyd , and .dll depending on your Operating System. These are the shared libraries that represent the dependencies of your project that PyInstaller created and collected.

Note: You can add *.spec , build/ , and dist/ to your .gitignore file to keep git status clean if you’re using git for version control. The default GitHub gitignore file for Python projects already does this for you.

You’ll want to distribute the entire dist/cli folder, but you can rename cli to anything that suits you.

At this point you can try running the dist/cli/cli executable if you’re following along with the feed reader example.

You’ll notice that running the executable results in errors mentioning the version.txt file. This is because the feed reader and its dependencies require some extra data files that PyInstaller doesn’t know about. To fix that, you’ll have to tell PyInstaller that version.txt is required, which you’ll learn about when testing your new executable.

Customizing Your Builds

PyInstaller comes with lots of options that can be provided as spec files or normal CLI options. Below, you’ll find some of the most common and useful options.

Change the name of your executable.

This is a way to avoid your executable, spec file, and build artifact folders being named after your entry-point script. —name is useful if you have a habit of naming your entry-point script something like cli.py , as I do.

You can build an executable called realpython from the cli.py script with a command like this:

Package your entire application into a single executable file.

The default options create a folder of dependencies and and executable, whereas —onefile keeps distribution easier by creating only an executable.

This option takes no arguments. To bundle your project into a single file, you can build with a command like this:

With the above command, your dist/ folder will only contain a single executable instead of a folder with all the dependencies in separate files.

List multiple top-level imports that PyInstaller was unable to detect automatically.

This is one way to work around your code using import inside functions and __import__() . You can also use —hidden-import multiple times in the same command.

This option requires the name of the package that you want to include in your executable. For example, if your project imported the requests library inside of a function, then PyInstaller would not automatically include requests in your executable. You could use the following command to force requests to be included:

You can specify this multiple times in your build command, once for each hidden import.

—add-data and —add-binary

Instruct PyInstaller to insert additional data or binary files into your build.

This is useful when you want to bundle in configuration files, examples, or other non-code data. You’ll see an example of this later if you’re following along with the feed reader project.

Exclude some modules from being included with your executable

This is useful to exclude developer-only requirements like testing frameworks. This is a great way to keep the artifact you give users as small as possible. For example, if you use pytest, you may want to exclude this from your executable:

Avoid automatically opening a console window for stdout logging.

This is only useful if you’re building a GUI-enabled application. This helps your hide the details of your implementation by allowing users to never see a terminal.

Similar to the —onefile option, -w takes no arguments:

As mentioned earlier, you can reuse the automatically generated .spec file to further customize your executable. The .spec file is a regular Python script that implicitly uses the PyInstaller library API.

Since it’s a regular Python script, you can do almost anything inside of it. You can refer to the official PyInstaller Spec file documentation for more information on that API.

Testing Your New Executable

The best way to test your new executable is on a new machine. The new machine should have the same OS as your build machine. Ideally, this machine should be as similar as possible to what your users use. That may not always be possible, so the next best thing is testing on your own machine.

The key is to run the resulting executable without your development environment activated. This means run without virtualenv , conda , or any other environment that can access your Python installation. Remember, one of the main goals of a PyInstaller-created executable is for users to not need anything installed on their machine.

Picking up with the feed reader example, you’ll notice that running the default cli executable in the dist/cli folder fails. Luckily the error points you to the problem:

The importlib_resources package requires a version.txt file. You can add this file to the build using the —add-data option. Here’s an example of how to include the required version.txt file:

This command tells PyInstaller to include the version.txt file in the importlib_resources folder in a new folder in your build called importlib_resources .

Note: The pyinstaller commands use the \ character to make the command easier to read. You can omit the \ when running commands on your own or copy and paste the commands as-is below provided you’re using the same paths.

You’ll want to adjust the path in the above command to match where you installed the feed reader dependencies.

Now running the new executable will result in a new error about a config.cfg file.

This file is required by the feed reader project, so you’ll need to make sure to include it in your build:

Again, you’ll need to adjust the path to the file based on where you have the feed reader project.

At this point, you should have a working executable that can be given directly to users!

Debugging PyInstaller Executables

As you saw above, you might encounter problems when running your executable. Depending on the complexity of your project, the fixes could be as simple as including data files like the feed reader example. However, sometimes you need more debugging techniques.

Below are a few common strategies that are in no particular order. Often times one of these strategies or a combination will lead to a break-through in tough debugging sessions.

Use the Terminal

First, try running the executable from a terminal so you can see all the output.

Remember to remove the -w build flag to see all the stdout in a console window. Often, you’ll see ImportError exceptions if a dependency is missing.

Debug Files

Inspect the build/cli/warn-cli.txt file for any problems. PyInstaller creates lots of output to help you understand exactly what it’s creating. Digging around in the build/ folder is a great place to start.

Single Directory Builds

Use the —onedir distribution mode of creating distribution folder instead of a single executable. Again, this is the default mode. Building with —onedir gives you the opportunity to inspect all the dependencies included instead of everything being hidden in a single executable.

—onedir is useful for debugging, but —onefile is typically easier for users to comprehend. After debugging you may want to switch to —onefile mode to simplify distribution.

Additional CLI Options

PyInstaller also has options to control the amount of information printed during the build process. Rebuild the executable with the —log-level=DEBUG option to PyInstaller and review the output.

PyInstaller will create a lot of output when increasing the verbosity with —log-level=DEBUG . It’s useful to save this output to a file you can refer to later instead of scrolling in your Terminal. To do this, you can use your shell’s redirection functionality. Here’s an example:

By using the above command, you’ll have a file called build.txt containing lots of additional DEBUG messages.

Note: The standard redirection with > is not sufficient. PyInstaller prints to the stderr stream, not stdout . This means you need to redirect the stderr stream to a file, which can be done using a 2 as in the previous command.

Here’s a sample of what your build.txt file might look like:

This file will have a lot of detailed information about what was included in your build, why something was not included, and how the executable was packaged.

You can also rebuild your executable using the —debug option in addition to using the —log-level option for even more information.

Note: The -y and —clean options are useful when rebuilding, especially when initially configuring your builds or building with Continuous Integration. These options remove old builds and omit the need for user input during the build process.

Additional PyInstaller Docs

The PyInstaller GitHub Wiki has lots of useful links and debugging tips. Most notably are the sections on making sure everything is packaged correctly and what to do if things go wrong.

Assisting in Dependency Detection

The most common problem you’ll see is ImportError exceptions if PyInstaller couldn’t properly detect all your dependencies. As mentioned before, this can happen if you’re using __import__() , imports inside functions, or other types of hidden imports.

Many of these types of problems can be resolved by using the —hidden-import PyInstaller CLI option. This tells PyInstaller to include a module or package even if it doesn’t automatically detect it. This is the easiest way to work around lots of dynamic import magic in your application.

Another way to work around problems is hook files. These files contain additional information to help PyInstaller package up a dependency. You can write your own hooks and tell PyInstaller to use them with the —additional-hooks-dir CLI option.

Hook files are how PyInstaller itself works internally so you can find lots of example hook files in the PyInstaller source code.

Limitations

PyInstaller is incredibly powerful, but it does have some limitations. Some of the limitations were discussed previously: hidden imports and relative imports in entry-point scripts.

PyInstaller supports making executables for Windows, Linux, and macOS, but it cannot cross compile. Therefore, you cannot make an executable targeting one Operating System from another Operating System. So, to distribute executables for multiple types of OS, you’ll need a build machine for each supported OS.

Related to the cross compile limitation, it’s useful to know that PyInstaller does not technically bundle absolutely everything your application needs to run. Your executable is still dependent on the users’ glibc . Typically, you can work around the glibc limitation by building on the oldest version of each OS you intend to target.

For example, if you want to target a wide array of Linux machines, then you can build on an older version of CentOS. This will give you compatibility with most versions newer than the one you build on. This is the same strategy described in PEP 0513 and is what the PyPA recommends for building compatible wheels.

In fact, you might want to investigate using the PyPA’s manylinux docker image for your Linux build environment. You could start with the base image then install PyInstaller along with all your dependencies and have a build image that supports most variants of Linux.

Conclusion

PyInstaller can help make complicated installation documents unnecessary. Instead, your users can simply run your executable to get started as quickly as possible. The PyInstaller workflow can be summed up by doing the following:

1. Create an entry-point script that calls your main function.
2. Install PyInstaller.
3. Run PyInstaller on your entry-point.
4. Test your new executable.
5. Ship your resulting dist/ folder to users.

Your users don’t have to know what version of Python you used or that your application uses Python at all!

Превращаем Python-скрипт в исполняемый файл

Обычно для запуска Python-скрипта нужно установить Python, потом все библиотеки, потом проверить зависимости и только потом можно запускать. Сегодня научимся собирать всё это в один файл — его можно будет запустить на любом компьютере, даже если там нет Python.

�� Что делаем: превращаем Python-скрипт в исполняемый файл, который можно потом будет запустить на любом компьютере.

�� Время: 5 минут.

✅ Понадобится: библиотека pyInstaller.

�� Коротко суть. С помощью библиотеки pyInstaller можно собрать все файлы, модули и зависимости в одном месте, привязать к ним интерпретатор Python, а потом обернуть это в один файл. Это значит, что мы получаем как бы виртуальный контейнер, в котором уже есть всё, что нужно для запуска скрипта, — без установки на свой компьютер.

Ставим pyInstaller

В командной строке или в терминале VS Code пишем команду. Командную строку после этого не закрываем — она нам ещё пригодится:

pip install pyinstaller

Переходим в папку со скриптом

Чтобы было проще собирать скрипт в один файл, нам нужно перейти в ту папку, где лежит наш исходный скрипт. Для этого в той же командной строке используем команду cd, после которой пишем полный путь к папке. Например, если скрипт лежит в папке Downloads, то команда будет выглядеть так:

Если всё прошло штатно, мы увидим название папки в конце приветствия командной строки:

Как работает скрипт, собранный в один файл

Есть два варианта работы библиотеки: собрать всё в одну папку или упаковать всё в один файл. Но на самом деле это всё примерно одно и то же, потому что итоговый файл работает так:

1. Создаёт виртуальную папку.
2. Распаковывает из себя все библиотеки, служебные файлы и исполняемый файл Python.
3. На основе этого создаёт виртуальную среду и подключает все нужные библиотеки
4. Запускает Python и уже в нём выполняет наш скрипт.

Получается, что на самом деле мы просто создаём оболочку для скрипта, а внутри всё работает точно так же, как если бы мы запускали этот скрипт по старинке.

Превращаем скрипт в исполняемый файл

Единственный параметр, который нам нужно указать при запуске — то, что результат нужен в виде единого файла. Для этого используется параметр —onefile — если его не будет, то библиотека сделает нам одну папку вместо одного файла.

Проверим работу упаковщика на примере скрипта из статьи про графический интерфейс в Python. Для этого нужно написать pyinstaller и через пробел — имя скрипта. Если скрипт называется gui.py, то команда будет выглядеть так:

pyinstaller —onefile gui.py

После запуска в папке со скриптом появятся две новых папки — build и dist. Первая нам не нужна, поэтому заходим в dist — там и лежит наш готовый файл. Если это делать в Windows, там будет лежать файл для Windows. Если делать на Mac OS, получится приложение для Mac OS.

Размер файла — 25 мегабайт, а всё потому, что кроме скрипта внутри находятся все используемые библиотеки

Проверяем работу

Запускаем файл — просто дважды щёлкаем на нём мышкой и смотрим, что произойдёт.

После запуска открывается терминал, где видны служебные сообщения от программы графического интерфейса. Через несколько секунд (когда подключатся все библиотеки) мы видим новое окошко с графическим интерфейсом — значит, мы всё сделали правильно и этот файл можно запускать независимо от того, есть Python на компьютере или нет.

Если почитать документацию, можно тонко настроить работу сборщика — например, чтобы не было консоли.