Python/PyInstaller/2. Using PyInstaller

원본은 아래 링크를 참조한다.

https://pyinstaller.org/en/stable/usage.html#windows

 

The syntax of the pyinstaller command is:

pyinstaller 명령의 구문은 다음과 같다.

pyinstaller [options] script [script …] | specfile

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

가장 간단한 경우에는 현재 디렉터리를 myscript.py 프로그램의 위치로 설정하고 다음을 실행한다.

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.

PyInstaller는 myscript.py를 분석하고 다음을 수행한다.

• 스크립트와 동일한 폴더에 myscript.spec을 작성한다.
• 폴더 빌드가 없는 경우 스크립트와 동일한 폴더에 폴더 빌드를 만든다.
• 빌드 폴더에 일부 로그 파일과 작업 파일을 쓴다.
• dist 폴더가 존재하지 않는 경우 스크립트와 동일한 폴더에 폴더를 생성한다.
• dist 폴더에 myscript 실행 폴더를 쓴다.

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:

dist 폴더에는 사용자에게 배포하는 번들 앱이 있다.

일반적으로 명령줄에서 하나의 스크립트 이름을 지정한다. 더 많은 이름을 지정하면 모두 분석되어 출력에 포함된다. 그러나 이름이 지정된 첫 번째 스크립트는 사양 파일과 실행 가능한 폴더 또는 파일의 이름을 제공한다. 해당 코드는 런타임 시 가장 먼저 실행된다.

특정 용도의 경우 myscript.spec의 내용을 편집할 수 있다(사양 파일 사용에 설명되어 있음). 이 작업을 수행한 후 스크립트 대신 사양 파일의 이름을 PyInstaller로 지정한다.

pyinstaller myscript.spec

The myscript.spec file contains most of the information provided by the options that were specified when pyinstaller (or pyi-makespec) was run with the script file as the argument. You typically do not need to specify any options when running pyinstaller with the spec file. Only a few command-line options have an effect when building from a spec file.

You may give a path to the script or spec file, for example

myscript.spec 파일에는 스크립트 파일을 인수로 사용하여 pyinstaller(또는 pyi-makespec)를 실행할 때 지정된 옵션이 제공하는 대부분의 정보가 포함되어 있다. 일반적으로 사양 파일을 사용하여 pyinstaller를 실행할 때 옵션을 지정할 필요가 없다. 사양 파일에서 빌드할 때 몇 가지 명령줄 옵션만 효과가 있다.

예를 들어 스크립트 또는 사양 파일에 대한 경로를 제공할 수 있다.

pyinstaller options… ~/myproject/source/myscript.py

or, on Windows,

또는 Windows에서는

pyinstaller "C:\Documents and Settings\project\myscript.spec"

Options

A full list of the pyinstaller command’s options are as follows:

pyinstaller 명령 옵션의 전체 목록은 다음과 같다:

Positional Arguments

scriptname

Name of scriptfiles to be processed or exactly one .spec file. If a .spec file is specified, most options are unnecessary and are ignored.

처리할 스크립트 파일의 이름 또는 정확히 하나의 .spec 파일이다. .spec 파일을 지정하면 대부분의 옵션이 필요하지 않으며 무시된다.

Options

-h, --help

show this help message and exit

이 도움말 메시지를 표시하고 종료한다.

 

-v, --version

Show program version info and exit.

프로그램 버전 정보를 표시하고 종료한다.

 

--distpath DIR

Where to put the bundled app (default: ./dist)

번들 앱을 넣을 위치(기본값: ./dist)

 

--workpath WORKPATH

Where to put all the temporary work files, .log, .pyz and etc. (default: ./build)

모든 임시 작업 파일(.log, .pyz 등)을 저장할 위치(기본값: ./build)

 

-y, --noconfirm

Replace output directory (default: SPECPATH/dist/SPECNAME) without asking for confirmation

확인을 요청하지 않고 출력 디렉터리(기본값: SPECPATH/dist/SPECNAME)를 바꾼다.

 

--upx-dir UPX_DIR

Path to UPX utility (default: search the execution path)

UPX 유틸리티 경로(기본값: 실행 경로 검색)

 

--clean

Clean PyInstaller cache and remove temporary files before building.

빌드하기 전에 PyInstaller 캐시를 정리하고 임시 파일을 제거한다.

 

--log-level LEVEL

Amount of detail in build-time console messages. LEVEL may be one of TRACE, DEBUG, INFO, WARN, DEPRECATION, ERROR, FATAL (default: INFO). Also settable via and overrides the PYI_LOG_LEVEL environment variable.

빌드 시간 콘솔 메시지의 세부 정보이다. LEVEL은 TRACE, DEBUG, INFO, WARN, DEPRECATION, ERROR, FATAL 중 하나일 수 있다(기본값: INFO). 또한 PYI_LOG_LEVEL 환경 변수를 통해 설정 가능하고 재정의된다.

What To Generate

-D, --onedir

Create a one-folder bundle containing an executable (default)

실행 파일이 포함된 단일 폴더 번들 생성(기본값)

 

-F, --onefile

Create a one-file bundled executable.

단일 파일 번들 실행 파일을 만든다.

 

--specpath DIR

Folder to store the generated spec file (default: current directory)

생성된 스펙 파일을 저장할 폴더 (기본값: 현재 디렉터리)

 

-n NAME, --name NAME

Name to assign to the bundled app and spec file (default: first script’s basename)

번들 앱 및 사양 파일에 할당할 이름(기본값: 첫 번째 스크립트의 기본 이름)

 

--contents-directory CONTENTS_DIRECTORY

For onedir builds only, specify the name of the directory in which all supporting files (i.e. everything except the executable itself) will be placed in. Use “.” to re-enable old onedir layout without contents directory.

onedir 빌드의 경우에만 모든 지원 파일(즉, 실행 파일 자체를 제외한 모든 파일)이 배치될 디렉터리 이름을 지정한다. "."를 사용하여 콘텐츠 디렉토리 없이 이전 onedir 레이아웃을 다시 활성화한다.

What To Bundle, Where To Search

--add-data SOURCE:DEST

Additional data files or directories containing data files to be added to the application. The argument value should be in form of “source:dest_dir”, where source is the path to file (or directory) to be collected, dest_dir is the destination directory relative to the top-level application directory, and both paths are separated by a colon (:). To put a file in the top-level application directory, use . as a dest_dir. This option can be used multiple times.

애플리케이션에 추가할 데이터 파일이 포함된 추가 데이터 파일 또는 디렉터리이다. 인수 값은 "source:dest_dir" 형식이어야 한다. 여기서 source는 수집할 파일(또는 디렉터리)의 경로이고, dest_dir은 최상위 응용 프로그램 디렉터리에 상대적인 대상 디렉터리이며, 두 경로는 모두 콜론(:)으로 구분된다. 최상위 애플리케이션 디렉토리에 파일을 넣으려면 . 을 dest_dir로 사용한다. 이 옵션은 여러 번 사용할 수 있다.

 

--add-binary SOURCE:DEST

Additional binary files to be added to the executable. See the --add-data option for the format. This option can be used multiple times.

실행 파일에 추가할 추가 바이너리 파일이다. 형식은 --add-data 옵션을 참조한다. 이 옵션은 여러 번 사용할 수 있다.

 

-p DIR, --paths DIR

A path to search for imports (like using PYTHONPATH). Multiple paths are allowed, separated by ':', or use this option multiple times. Equivalent to supplying the pathex argument in the spec file.

가져오기를 검색하기 위한 경로이다(예: PYTHONPATH 사용). 여러 경로가 허용되며 ':'으로 구분되거나 이 옵션을 여러 번 사용한다. 사양 파일에 pathex 인수를 제공하는 것과 동일하다.

 

--hidden-import MODULENAME, --hiddenimport MODULENAME

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

스크립트 코드에 표시되지 않는 가져오기 이름을 지정한다. 이 옵션은 여러 번 사용할 수 있다.

 

--collect-submodules MODULENAME

Collect all submodules from the specified package or module. This option can be used multiple times.

지정된 패키지 또는 모듈에서 모든 하위 모듈을 수집한다. 이 옵션은 여러 번 사용할 수 있다.

 

--collect-data MODULENAME, --collect-datas MODULENAME

Collect all data from the specified package or module. This option can be used multiple times.

지정된 패키지 또는 모듈에서 모든 데이터를 수집한다. 이 옵션은 여러 번 사용할 수 있다.

 

--collect-binaries MODULENAME

Collect all binaries from the specified package or module. This option can be used multiple times.

지정된 패키지 또는 모듈에서 모든 바이너리를 수집한다. 이 옵션은 여러 번 사용할 수 있다.

 

--collect-all MODULENAME

Collect all submodules, data files, and binaries from the specified package or module. This option can be used multiple times.

지정된 패키지 또는 모듈에서 모든 하위 모듈, 데이터 파일 및 바이너리를 수집한다. 이 옵션은 여러 번 사용할 수 있다.

 

--copy-metadata PACKAGENAME

Copy metadata for the specified package. This option can be used multiple times.

지정된 패키지에 대한 메타데이터를 복사한다. 이 옵션은 여러 번 사용할 수 있다.

 

--recursive-copy-metadata PACKAGENAME

Copy metadata for the specified package and all its dependencies. 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 (the Python name, not the path name) that will be ignored (as though it was not found). This option can be used multiple times.

(찾지 못한 것처럼) 무시될 선택적 모듈 또는 패키지(경로 이름이 아닌 Python 이름). 이 옵션은 여러 번 사용할 수 있다.

 

--splash IMAGE_FILE

(EXPERIMENTAL) Add an splash screen with the image IMAGE_FILE to the application. The splash screen can display progress updates while unpacking.

(실험적) IMAGE_FILE 이미지가 포함된 스플래시 화면을 애플리케이션에 추가한다. 스플래시 화면은 압축을 푸는 동안 진행 상황 업데이트를 표시할 수 있다.

How To Generate

-d {all,imports,bootloader,noarchive}, --debug {all,imports,bootloader,noarchive}

Provide assistance with debugging a frozen application. This argument may be provided multiple times to select several of the following options. - all: All three of the following options. - imports: specify the -v option to the underlying Python interpreter, causing it to print a message each time a module is initialized, showing the place (filename or built-in module) from which it is loaded. See https://docs.python.org/3/using/cmdline.html#id4. - bootloader: tell the bootloader to issue progress messages while initializing and starting the bundled app. Used to diagnose problems with missing imports. - noarchive: instead of storing all frozen Python source files as an archive inside the resulting executable, store them as files in the resulting output directory.

정지된 애플리케이션 디버깅에 대한 지원을 제공한다. 이 인수는 다음 옵션 중 여러 개를 선택하기 위해 여러 번 제공될 수 있다.

- all: 다음 세 가지 옵션을 모두 선택한다.

- imports: 기본 Python 인터프리터에 -v 옵션을 지정하면 모듈이 초기화될 때마다 메시지가 인쇄되어 로드된 위치(파일 이름 또는 내장 모듈)가 표시된다. https://docs.python.org/3/using/cmdline.html#id4를 참조한다.

- bootloader: 번들 앱을 초기화하고 시작하는 동안 진행 메시지를 발행하도록 부트로더에 지시한다. 누락된 가져오기 문제를 진단하는 데 사용된다.

- noarchive: 모든 고정된 Python 소스 파일을 결과 실행 파일 내부의 아카이브로 저장하는 대신 결과 출력 디렉터리에 파일로 저장한다.

 

--optimize LEVEL

Bytecode optimization level used for collected python modules and scripts. For details, see the section “Bytecode Optimization Level” in PyInstaller manual.

수집된 Python 모듈 및 스크립트에 사용되는 바이트코드 최적화 수준이다. 자세한 내용은 PyInstaller 매뉴얼의 "바이트코드 최적화 수준" 섹션을 참조한다.

 

--python-option PYTHON_OPTION

Specify a command-line option to pass to the Python interpreter at runtime. Currently supports “v” (equivalent to “–debug imports”), “u”, “W ”, “X ”, and “hash_seed=”. For details, see the section “Specifying Python Interpreter Options” in PyInstaller manual.

런타임 시 Python 인터프리터에 전달할 명령줄 옵션을 지정한다. 현재 “v”(“–debug imports”와 동일), “u”, “`W `”, “`X `” 및 “`hash_seed=`”를 지원한다. 자세한 내용은 PyInstaller 매뉴얼의 "Python 인터프리터 옵션 지정" 섹션을 참조한다.

 

-s, --strip

Apply a symbol-table strip to the executable and shared libs (not recommended for Windows)

실행 파일 및 공유 라이브러리에 기호 테이블 스트립을 적용한다(Windows에서는 권장되지 않음).

 

--noupx

Do not use UPX even if it is available (works differently between Windows and *nix)

UPX가 사용 가능하더라도 사용하지 않는다(Windows와 *nix 간에는 다르게 작동함).

 

--upx-exclude FILE

Prevent a binary from being compressed when using upx. This is typically used if upx corrupts certain binaries during compression. FILE is the filename of the binary without path. This option can be used multiple times.

upx를 사용할 때 바이너리가 압축되는 것을 방지한다. 이는 일반적으로 압축 중에 upx가 특정 바이너리를 손상시키는 경우에 사용된다. FILE은 경로가 없는 바이너리의 파일 이름이다. 이 옵션은 여러 번 사용할 수 있다.

Windows And Mac Os X Specific Options

-c, --console, --nowindowed

Open a console window for standard i/o (default). On Windows this option has no effect if the first script is a ‘.pyw’ file.

표준 I/O용 콘솔 창을 연다(기본값). Windows에서 첫 번째 스크립트가 '.pyw' 파일인 경우 이 옵션은 효과가 없다.

 

-w, --windowed, --noconsole

Windows and Mac OS X: do not provide a console window for standard i/o. On Mac OS this also triggers building a Mac OS .app bundle. On Windows this option is automatically set if the first script is a ‘.pyw’ file. This option is ignored on *NIX systems.

Windows 및 Mac OS X: 표준 I/O용 콘솔 창을 제공하지 않는다. Mac OS에서는 Mac OS .app 번들 빌드도 트리거된다. Windows에서는 첫 번째 스크립트가 '.pyw' 파일인 경우 이 옵션이 자동으로 설정된다. 이 옵션은 *NIX 시스템에서는 무시된다.

 

--hide-console {hide-early,minimize-late,hide-late,minimize-early}

Windows only: in console-enabled executable, have bootloader automatically hide or minimize the console window if the program owns the console window (i.e., was not launched from an existing console window).

Windows에만 해당: 콘솔 지원 실행 파일에서 프로그램이 콘솔 창을 소유한 경우(즉, 기존 콘솔 창에서 실행되지 않은 경우) 부트로더가 자동으로 콘솔 창을 숨기거나 최소화하도록 한다.

 

-i , --icon

FILE.ico: apply the icon to a Windows executable. FILE.exe,ID: extract the icon with ID from an exe. FILE.icns: apply the icon to the .app bundle on Mac OS. If an image file is entered that isn’t in the platform format (ico on Windows, icns on Mac), PyInstaller tries to use Pillow to translate the icon into the correct format (if Pillow is installed). Use “NONE” to not apply any icon, thereby making the OS show some default (default: apply PyInstaller’s icon). This option can be used multiple times.

FILE.ico: Windows 실행 파일에 아이콘을 적용한다. FILE.exe,ID: exe에서 ID가 포함된 아이콘을 추출한다. FILE.icns: Mac OS의 .app 번들에 아이콘을 적용한다. 플랫폼 형식(Windows의 경우 ico, Mac의 경우 icns)이 아닌 이미지 파일을 입력하면 PyInstaller는 Pillow를 사용하여 아이콘을 올바른 형식(Pillow가 설치된 경우)으로 변환하려고 한다. 아이콘을 적용하지 않으려면 "NONE"을 사용하여 OS에 기본값을 표시한다(기본값: PyInstaller의 아이콘 적용). 이 옵션은 여러 번 사용할 수 있다.

 

--disable-windowed-traceback

Disable traceback dump of unhandled exception in windowed (noconsole) mode (Windows and macOS only), and instead display a message that this feature is disabled.

창 모드(콘솔 없음) 모드(Windows 및 macOS만 해당)에서 처리되지 않은 예외의 역추적 덤프를 비활성화하고 대신 이 기능이 비활성화되었다는 메시지를 표시한다.

Windows Specific Options

--version-file FILE

Add a version resource from FILE to the exe.

FILE의 버전 리소스를 exe에 추가한다.

 

-m , --manifest

Add manifest FILE or XML to the exe.

exe에 매니페스트 FILE 또는 XML을 추가한다.

 

-r RESOURCE, --resource RESOURCE

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.

Windows 실행 파일에 리소스를 추가하거나 업데이트한다. RESOURCE는 FILE[,TYPE[,NAME[,LANGUAGE]]]의 1~4개 항목이다. FILE은 데이터 파일이거나 exe/dll일 수 있다. 데이터 파일의 경우 최소한 TYPE 및 NAME을 지정해야 한다. LANGUAGE의 기본값은 0이거나 주어진 TYPE 및 NAME의 모든 리소스를 업데이트하기 위해 와일드카드 *로 지정될 수 있다. exe/dll 파일의 경우 TYPE, NAME 및 LANGUAGE가 생략되거나 와일드카드 *로 지정되면 FILE의 모든 리소스가 최종 실행 파일에 추가/업데이트된다. 이 옵션은 여러 번 사용할 수 있다.

 

--uac-admin

Using this option creates a Manifest that will request elevation upon application start.

이 옵션을 사용하면 애플리케이션 시작 시 권한 상승을 요청하는 매니페스트가 생성된다.

 

--uac-uiaccess

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

이 옵션을 사용하면 관리자 권한 애플리케이션이 원격 데스크톱과 작동할 수 있다.

Mac Os Specific Options

--argv-emulation

Enable argv emulation for macOS app bundles. If enabled, the initial open document/URL event is processed by the bootloader and the passed file paths or URLs are appended to sys.argv.

macOS 앱 번들에 대해 argv 에뮬레이션을 활성화한다. 활성화되면 초기 열린 문서/URL 이벤트가 부트로더에 의해 처리되고 전달된 파일 경로 또는 URL이 sys.argv에 추가된다.

 

--osx-bundle-identifier BUNDLE_IDENTIFIER

Mac OS .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)

Mac OS .app 번들 식별자는 코드 서명을 위한 기본 고유 프로그램 이름으로 사용된다. 일반적인 형식은 역방향 DNS 표기법을 따른 계층적 이름이다. 예: com.mycompany.department.appname (기본값: 첫 번째 스크립트의 기본 이름)

 

--target-architecture ARCH, --target-arch ARCH

Target architecture (macOS only; valid values: x86_64, arm64, universal2). Enables switching between universal2 and single-arch version of frozen application (provided python installation supports the target architecture). If not target architecture is not specified, the current running architecture is targeted.

대상 아키텍처(macOS만 해당, 유효한 값: x86_64, arm64, universal2). 고정된 애플리케이션의 universal2 버전과 단일 아키텍처 버전 간 전환이 가능하다(Python 설치가 대상 아키텍처를 지원하는 경우). 대상 아키텍처가 지정되지 않은 경우 현재 실행 중인 아키텍처가 대상이 된다.

 

--codesign-identity IDENTITY

Code signing identity (macOS only). Use the provided identity to sign collected binaries and generated executable. If signing identity is not provided, ad- hoc signing is performed instead.

코드 서명 ID(macOS에만 해당) 제공된 ID를 사용하여 수집된 바이너리 및 생성된 실행 파일에 서명한다. 서명 ID가 제공되지 않으면 임시 서명이 대신 수행된다.

 

--osx-entitlements-file FILENAME

Entitlements file to use when code-signing the collected binaries (macOS only).

수집된 바이너리를 코드 서명할 때 사용할 권한 파일이다(macOS에만 해당).

Rarely Used Special Options

--runtime-tmpdir PATH

Where to extract libraries and support files in onefile mode. If this option is given, the bootloader will ignore any temp-folder location defined by the run-time OS. The _MEIxxxxxx-folder will be created here. Please use this option only if you know what you are doing. Note that on POSIX systems, PyInstaller’s bootloader does NOT perform shell-style environment variable expansion on the given path string. Therefore, using environment variables (e.g., ~ or $HOME) in path will NOT work.

단일 파일 모드에서 라이브러리 및 지원 파일을 추출할 위치이다. 이 옵션이 제공되면 부트로더는 런타임 OS에서 정의한 임시 폴더 위치를 무시한다. 여기에 _MEIxxxxxx 폴더가 생성된다. 현재 수행 중인 작업을 알고 있는 경우에만 이 옵션을 사용한다. POSIX 시스템에서 PyInstaller의 부트로더는 주어진 경로 문자열에서 쉘 스타일 환경 변수 확장을 수행하지 않는다. 따라서 경로에 환경 변수(예: ~ 또는 $HOME)를 사용하면 작동하지 않는다.

 

--bootloader-ignore-signals

Tell the bootloader to ignore signals rather than forwarding them to the child process. Useful in situations where for example a supervisor process signals both the bootloader and the child (e.g., via a process group) to avoid signalling the child twice.

신호를 하위 프로세스로 전달하는 대신 신호를 무시하도록 부트로더에 지시한다. 예를 들어 감독자 프로세스가 부트로더와 하위 모두에 신호를 보내는 상황(예: 프로세스 그룹을 통해)에 유용하여 하위에 두 번 신호를 보내는 것을 방지한다.

Shortening the Command

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 GNU/Linux:

옵션이 많기 때문에 전체 pyinstaller 명령이 매우 길어질 수 있다. 스크립트를 개발하면서 동일한 명령을 계속해서 실행하게 된다. 읽을 수 있도록 연속된 줄을 사용하여 쉘 스크립트나 배치 파일에 명령을 넣을 수 있다. 예를 들어, GNU/Linux에서는:

pyinstaller --noconfirm --log-level=WARN \
    --onefile --nowindow \
    --add-data="README:." \
    --add-data="image1.png:img" \
    --add-binary="libfoo.so:lib" \
    --hidden-import=secret1 \
    --hidden-import=secret2 \
    --upx-dir=/usr/local/share/ \
    myscript.spec

Or in Windows, use the little-known BAT file line continuation:

또는 Windows에서는 잘 알려지지 않은 BAT 파일 줄 연속을 사용한다.

pyinstaller --noconfirm --log-level=WARN ^
    --onefile --nowindow ^
    --add-data="README:." ^
    --add-data="image1.png:img" ^
    --add-binary="libfoo.so:lib" ^
    --hidden-import=secret1 ^
    --hidden-import=secret2 ^
    --icon=..\MLNMFLCN.ICO ^
    myscript.spec

Running PyInstaller from Python code

If you want to run PyInstaller from Python code, you can use the run function defined in PyInstaller.__main__. For instance, the following code:

Python 코드에서 PyInstaller를 실행하려면 PyInstaller.__main__에 정의된 실행 함수를 사용할 수 있다. 예를 들어 다음 코드는 다음과 같다.

import PyInstaller.__main__

PyInstaller.__main__.run([
    'my_script.py',
    '--onefile',
    '--windowed'
])

Is equivalent to:

다음과 같다:

pyinstaller my_script.py --onefile --windowed

Using UPX

UPX is a free utility for compressing executable files and libraries. It 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 file formats.

When UPX is available, PyInstaller uses it to individually compress each collected binary file (executable, shared library, or python extension) in order to reduce the overall size of the frozen application (the one-dir bundle directory, or the one-file executable). The frozen application’s executable itself is not UPX-compressed (regardless of one-dir or one-file mode), as most of its size comprises the embedded archive that already contains individually compressed files.

PyInstaller looks for the UPX in the standard executable path(s) (defined by PATH environment variable), or in the path specified via the --upx-dir command-line option. If found, it is used automatically. The use of UPX can be completely disabled using the --noupx command-line option.

UPX는 실행 파일과 라이브러리를 압축하는 무료 유틸리티이다. 대부분의 운영 체제에서 사용할 수 있으며 다양한 실행 파일 형식을 압축할 수 있다. 다운로드 및 지원되는 파일 형식 목록은 UPX 홈 페이지를 참조한다.

UPX를 사용할 수 있는 경우 PyInstaller는 이를 사용하여 수집된 각 바이너리 파일(실행 파일, 공유 라이브러리 또는 Python 확장)을 개별적으로 압축하여 고정된 애플리케이션(1개 디렉터리 번들 디렉터리 또는 단일 파일 실행 파일)의 전체 크기를 줄인다. 동결된 애플리케이션의 실행 파일 자체는 UPX 압축되지 않다(단일 디렉터리 또는 단일 파일 모드에 관계없이). 왜냐하면 해당 크기의 대부분은 이미 개별적으로 압축된 파일이 포함된 내장 아카이브로 구성되기 때문이다.

PyInstaller는 표준 실행 파일 경로(PATH 환경 변수로 정의됨) 또는 --upx-dir 명령줄 옵션을 통해 지정된 경로에서 UPX를 찾는다. 발견되면 자동으로 사용된다. --noupx 명령줄 옵션을 사용하면 UPX 사용을 완전히 비활성화할 수 있다.

Note

UPX is currently used only on Windows. On other operating systems, the collected binaries are not processed even if UPX is found. The shared libraries (e.g., the Python shared library) built on modern linux distributions seem to break when processed with UPX, resulting in defunct application bundles. On macOS, UPX currently fails to process .dylib shared libraries; furthermore the UPX-compressed files fail the validation check of the codesign utility, and therefore cannot be code-signed (which is a requirement on the Apple M1 platform).

UPX는 현재 Windows에서만 사용된다. 다른 운영 체제에서는 UPX가 발견되더라도 수집된 바이너리가 처리되지 않다. 최신 Linux 배포판에 구축된 공유 라이브러리(예: Python 공유 라이브러리)는 UPX로 처리할 때 작동하지 않는 애플리케이션 번들이 발생하는 것으로 보인다. macOS에서 UPX는 현재 .dylib 공유 라이브러리를 처리하지 못한다. 또한 UPX 압축 파일은 codesign 유틸리티의 유효성 검사에 실패하므로 코드 서명을 할 수 없다(Apple M1 플랫폼의 요구 사항).

Excluding problematic files from UPX processing

Using UPX may end up corrupting a collected shared library. Known examples of such corruption are Windows DLLs with Control Flow Guard (CFG) enabled, as well as Qt5 and Qt6 plugins. In such cases, individual files may be need to be excluded from UPX processing, using the --upx-exclude option (or using the upx_exclude argument in the .spec file).

Changed in version 4.2: PyInstaller detects CFG-enabled DLLs and automatically excludes them from UPX processing.

Changed in version 4.3: PyInstaller automatically excludes Qt5 and Qt6 plugins from UPX processing.

Although PyInstaller attempts to automatically detect and exclude some of the problematic files from UPX processing, there are cases where the UPX excludes need to be specified manually. For example, 32-bit Windows binaries from the PySide2 package (Qt5 DLLs and python extension modules) have been reported to be corrupted by UPX.

Changed in version 5.0: Unlike earlier releases that compared the provided UPX-exclude names against basenames of the collect binary files (and, due to incomplete case normalization, required provided exclude names to be lowercase on Windows), the UPX-exclude pattern matching now uses OS-default case sensitivity and supports the wildcard (*) operator. It also supports specifying (full or partial) parent path of the file.

The provided UPX exclude patterns are matched against source (origin) paths of the collected binary files, and the matching is performed from right to left.

For example, to exclude Qt5 DLLs from the PySide2 package, use --upx-exclude "Qt*.dll", and to exclude the python extensions from the PySide2 package, use --upx-exclude "PySide2\*.pyd".

UPX를 사용하면 수집된 공유 라이브러리가 손상될 수 있다. 이러한 손상의 알려진 예로는 CFG(Control Flow Guard)가 활성화된 Windows DLL과 Qt5 및 Qt6 플러그인이 있다. 이러한 경우 --upx-exclude 옵션을 사용하거나 .spec 파일의 upx_exclude 인수를 사용하여 개별 파일을 UPX 처리에서 제외해야 할 수도 있다.

버전 4.2에서 변경: PyInstaller는 CFG 지원 DLL을 감지하고 UPX 처리에서 자동으로 제외한다.

버전 4.3에서 변경: PyInstaller는 UPX 처리에서 Qt5 및 Qt6 플러그인을 자동으로 제외한다.

PyInstaller는 UPX 처리에서 문제가 있는 일부 파일을 자동으로 감지하고 제외하려고 시도하지만 UPX 제외를 수동으로 지정해야 하는 경우가 있다. 예를 들어, PySide2 패키지(Qt5 DLL 및 Python 확장 모듈)의 32비트 Windows 바이너리가 UPX에 의해 손상된 것으로 보고되었다.

버전 5.0에서 변경됨: 제공된 UPX 제외 이름을 수집 바이너리 파일의 기본 이름과 비교한 이전 릴리스와 달리(그리고 불완전한 대소문자 정규화로 인해 제공된 제외 이름이 Windows에서 소문자여야 함) 이제 UPX 제외 패턴 일치 OS 기본 대소문자 구분을 사용하고 와일드카드(*) 연산자를 지원한다. 또한 파일의 상위 경로(전체 또는 부분) 지정을 지원한다.

제공된 UPX 제외 패턴은 수집된 바이너리 파일의 소스(원본) 경로와 일치하며 오른쪽에서 왼쪽으로 일치가 수행된다.

예를 들어, PySide2 패키지에서 Qt5 DLL을 제외하려면 --upx-exclude "Qt*.dll"을 사용하고, PySide2 패키지에서 Python 확장을 제외하려면 --upx-exclude "`PySide2\*.pyd`"를 사용한다.

Splash Screen (Experimental)

Note

This feature is incompatible with macOS. In the current design, the splash screen operates in a secondary thread, which is disallowed by the Tcl/Tk (or rather, the underlying GUI toolkit) on macOS.

이 기능은 macOS와 호환되지 않다. 현재 디자인에서 스플래시 화면은 macOS의 Tcl/Tk(또는 기본 GUI 툴킷)에서 허용되지 않는 보조 스레드에서 작동한다.

Some applications may require a splash screen as soon as the application (bootloader) has been started, because especially in onefile mode large applications may have long extraction/startup times, while the bootloader prepares everything, where the user cannot judge whether the application was started successfully or not.

The bootloader is able to display a one-image (i.e. only an image) splash screen, which is displayed before the actual main extraction process starts. The splash screen supports non-transparent and hard-cut-transparent images as background image, so non-rectangular splash screens can also be displayed.

일부 응용 프로그램은 응용 프로그램(부트로더)이 시작되자마자 스플래시 화면이 필요할 수 있다. 특히 단일 파일 모드에서 대형 응용 프로그램은 추출/시작 시간이 길고 부트로더가 모든 것을 준비하므로 사용자가 응용 프로그램이 성공적으로 시작되었는지 여부를 판단할 수 없기 때문이다.

부트로더는 실제 기본 추출 프로세스가 시작되기 전에 표시되는 단일 이미지(즉, 이미지만) 스플래시 화면을 표시할 수 있다. 스플래시 화면은 배경 이미지로 불투명 및 하드 컷 투명 이미지를 지원하므로 직사각형이 아닌 스플래시 화면도 표시할 수 있다.

Note

Splash images with transparent regions are not supported on Linux due to Tcl/Tk platform limitations. The -transparentcolor and -transparent wm attributes used by PyInstaller are not available to Linux.

투명 영역이 있는 스플래시 이미지는 Tcl/Tk 플랫폼 제한으로 인해 Linux에서 지원되지 않다. PyInstaller에서 사용되는 -transparentcolor 및 -transparent wm 속성은 Linux에서 사용할 수 없다.

This splash screen is based on Tcl/Tk, which is the same library used by the Python module tkinter. PyInstaller bundles the dynamic libraries of tcl and tk into the application at compile time. These are loaded into the bootloader at startup of the application after they have been extracted (if the program has been packaged as an onefile archive). Since the file sizes of the necessary dynamic libraries are very small, there is almost no delay between the start of the application and the splash screen. The compressed size of the files necessary for the splash screen is about 1.5 MB.

As an additional feature, text can optionally be displayed on the splash screen. This can be changed/updated from within Python. This offers the possibility to display the splash screen during longer startup procedures of a Python program (e.g. waiting for a network response or loading large files into memory). You can also start a GUI behind the splash screen, and only after it is completely initialized the splash screen can be closed. Optionally, the font, color and size of the text can be set. However, the font must be installed on the user system, as it is not bundled. If the font is not available, a fallback font is used.

If the splash screen is configured to show text, it will automatically (as onefile archive) display the name of the file that is currently being unpacked, this acts as a progress bar.

이 스플래시 화면은 Python 모듈 tkinter에서 사용하는 것과 동일한 라이브러리인 Tcl/Tk를 기반으로 한다. PyInstaller는 컴파일 타임에 tcl과 tk의 동적 라이브러리를 애플리케이션에 번들로 묶는다. 이는 추출된 후(프로그램이 단일 파일 아카이브로 패키지된 경우) 응용 프로그램 시작 시 부트로더에 로드된다. 필요한 동적 라이브러리의 파일 크기가 매우 작기 때문에 애플리케이션 시작과 스플래시 화면 사이에 지연이 거의 없다. 스플래시 화면에 필요한 파일의 압축 크기는 약 1.5MB이다.

추가 기능으로 선택적으로 시작 화면에 텍스트를 표시할 수 있다. 이는 Python 내에서 변경/업데이트될 수 있다. 이는 Python 프로그램의 긴 시작 절차(예: 네트워크 응답을 기다리거나 대용량 파일을 메모리에 로드하는 등) 중에 시작 화면을 표시할 수 있는 가능성을 제공한다. 스플래시 화면 뒤에서 GUI를 시작할 수도 있으며 완전히 초기화된 후에만 스플래시 화면을 닫을 수 있다. 선택적으로 텍스트의 글꼴, 색상 및 크기를 설정할 수 있다. 단, 해당 글꼴은 번들로 제공되지 않으므로 사용자 시스템에 설치해야 한다. 글꼴을 사용할 수 없는 경우 대체 글꼴이 사용된다.

스플래시 화면이 텍스트를 표시하도록 구성된 경우 현재 압축을 풀고 있는 파일 이름이 자동으로(하나의 파일 아카이브로) 표시되며 이는 진행률 표시줄 역할을 한다.

The pyi_splash Module

The splash screen is controlled from within Python by the pyi_splash module, which can be imported at runtime. This module cannot be installed by a package manager because it is part of PyInstaller and is included as needed. This module must be imported within the Python program. The usage is as follows:

스플래시 화면은 런타임에 가져올 수 있는 pyi_splash 모듈에 의해 Python 내에서 제어된다. 이 모듈은 PyInstaller의 일부이고 필요에 따라 포함되므로 패키지 관리자가 설치할 수 없다. 이 모듈은 Python 프로그램 내에서 가져와야 한다. 사용법은 다음과 같다.

import pyi_splash

# Update the text on the splash screen
pyi_splash.update_text("PyInstaller is a great software!")
pyi_splash.update_text("Second time's a charm!")

# Close the splash screen. It does not matter when the call
# to this function is made, the splash screen remains open until
# this function is called or the Python program is terminated.
pyi_splash.close()

Of course the import should be in a try ... except block, in case the program is used externally as a normal Python script, without a bootloader. For a detailed description see pyi_splash Module (Detailed).

물론, 프로그램이 부트로더 없이 일반 Python 스크립트로 외부에서 사용되는 경우 import는 try ... Except 블록에 있어야 한다. 자세한 설명은 pyi_splash 모듈(상세)을 참조한다.

Defining the Extraction Location

When building your application in onefile mode (see Bundling to One File and How the One-File Program Works), you might encounter situations where you want to control the location of the temporary directory where the application unpacks itself. For example:

• your application is supposed to be running for long periods of time, and you need to prevent its files from being deleted by the OS that performs periodic clean-up in standard temporary directories.
• your target POSIX system does not use standard temporary directory location (i.e., /tmp) and the standard environment variables for temporary directory are not set in the environment.
• the default temporary directory on the target POSIX system is mounted with noexec option, which prevents the frozen application from loading the unpacked shared libraries.

단일 파일 모드에서 응용 프로그램을 빌드할 때(하나의 파일로 묶기 및 단일 파일 프로그램 작동 방식 참조) 응용 프로그램의 압축이 풀리는 임시 디렉터리의 위치를 ​​제어하려는 상황에 직면할 수 있다. 예를 들어:

• 애플리케이션은 오랜 기간 동안 실행되어야 하며, 표준 임시 디렉터리에서 정기적으로 정리를 수행하는 OS에 의해 해당 파일이 삭제되는 것을 방지해야 한다.
• 대상 POSIX 시스템은 표준 임시 디렉터리 위치(예: /tmp)를 사용하지 않으며 임시 디렉터리에 대한 표준 환경 변수가 환경에 설정되어 있지 않다.
• 대상 POSIX 시스템의 기본 임시 디렉토리는 noexec 옵션으로 마운트되어 고정된 애플리케이션이 압축이 풀린 공유 라이브러리를 로드하는 것을 방지한다.

The location of the temporary directory can be overridden dynamically, by setting corresponding environment variable(s) before launching the application, or set statically, using the --runtime-tmpdir option during the build process.

임시 디렉토리의 위치는 애플리케이션을 시작하기 전에 해당 환경 변수를 설정하여 동적으로 재정의하거나 빌드 프로세스 중에 --runtime-tmpdir 옵션을 사용하여 정적으로 설정할 수 있다.

Using environment variables

The extraction location can be controlled dynamically, by setting the environment variable(s) that PyInstaller uses to determine the temporary directory. This can, for example, be done in a wrapper shell script that sets the environment variable(s) before running the frozen application’s executable.

On POSIX systems, the environment variables used for temporary directory location are TMPDIR, TEMP, and TMP, in that order; if none are defined (or the corresponding directories do not exist or cannot be used), /tmp, /var/tmp, and /usr/tmp are used as hard-coded fall-backs, in the specified order. The directory specified via the environment variable must exist (i.e., the application attempts to create only its own directory under the base temporary directory).

On Windows, the default temporary directory location is determined via GetTempPathW function (which looks at TMP and TEMP environment variables for initial temporary directory candidates).

PyInstaller가 임시 디렉터리를 결정하는 데 사용하는 환경 변수를 설정하여 추출 위치를 동적으로 제어할 수 있다. 예를 들어 고정된 애플리케이션의 실행 파일을 실행하기 전에 환경 변수를 설정하는 래퍼 셸 스크립트에서 이 작업을 수행할 수 있다.

POSIX 시스템에서 임시 디렉터리 위치에 사용되는 환경 변수는 TMPDIR, TEMP, TMP 순서이다. 아무것도 정의되지 않은 경우(또는 해당 디렉터리가 존재하지 않거나 사용할 수 없는 경우) /tmp, /var/tmp 및 /usr/tmp는 지정된 순서대로 하드 코딩된 대체 항목으로 사용된다. 환경 변수를 통해 지정된 디렉터리가 존재해야 한다(즉, 애플리케이션은 기본 임시 디렉터리 아래에 자체 디렉터리만 생성하려고 시도한다).

Windows에서 기본 임시 디렉터리 위치는 GetTempPathW 함수(초기 임시 디렉터리 후보에 대한 TMP 및 TEMP 환경 변수 확인)를 통해 결정된다.

Using the --runtime-tmpdir option

The location of the temporary directory can be set statically, at compile time, using the --runtime-tmpdir option. If this option is used, the bootloader will ignore temporary directory locations defined by the OS, and use the specified path. The path can be either absolute or relative (which makes it relative to the current working directory).

Please use this option only if you know what you are doing.

임시 디렉토리의 위치는 --runtime-tmpdir 옵션을 사용하여 컴파일 타임에 정적으로 설정할 수 있다. 이 옵션을 사용하면 부트로더는 OS에서 정의한 임시 디렉터리 위치를 무시하고 지정된 경로를 사용한다. 경로는 절대 경로이거나 상대 경로일 수 있다(현재 작업 디렉터리를 기준으로 한다).

현재 수행 중인 작업을 알고 있는 경우에만 이 옵션을 사용한다.

Note

On POSIX systems, PyInstaller’s bootloader does not perform shell-style environment variable expansion on the path string given via --runtime-tmpdir option. Therefore, using environment variables (e.g., ~ or $HOME) in the path will not work.

POSIX 시스템에서 PyInstaller의 부트로더는 --runtime-tmpdir 옵션을 통해 제공된 경로 문자열에 대해 쉘 스타일 환경 변수 확장을 수행하지 않는다. 따라서 경로에 환경 변수(예: ~ 또는 $HOME)를 사용하면 작동하지 않는다.

Supporting Multiple Platforms

If you distribute your application for only one combination of OS and Python, just install PyInstaller like any other package and use it in your normal development setup.

OS와 Python의 한 가지 조합에 대해서만 애플리케이션을 배포하는 경우 다른 패키지처럼 PyInstaller를 설치하고 일반 개발 설정에서 사용한다.

Supporting Multiple Python Environments

When you need to bundle your application within one OS but for different versions of Python and support libraries – for example, a Python 3.6 version and a Python 3.7 version; or a supported version that uses Qt4 and a development version that uses Qt5 – we recommend you use venv. With venv you can maintain different combinations of Python and installed packages, and switch from one combination to another easily. These are called virtual environments or venvs in short.

• Use venv to create as many different development environments as you need, each with its unique combination of Python and installed packages.
• Install PyInstaller in each virtual environment.
• Use PyInstaller to build your application in each virtual environment.

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

• Windows: ENV_ROOT\Scripts
• Others: ENV_ROOT/bin

Under Windows, the pip-Win package makes it especially easy to set up different environments and switch between them. Under GNU/Linux and macOS, you switch environments at the command line.

See PEP 405 and the official Python Tutorial on Virtual Environments and Packages for more information about Python virtual environments.

하나의 OS 내에서 애플리케이션을 번들로 묶어야 하지만 서로 다른 버전의 Python 및 지원 라이브러리(예: Python 3.6 버전 및 Python 3.7 버전)에 대해 번들링해야 하는 경우 또는 Qt4를 사용하는 지원 버전과 Qt5를 사용하는 개발 버전 – venv를 사용하는 것이 좋다. venv를 사용하면 Python과 설치된 패키지의 다양한 조합을 유지하고 한 조합에서 다른 조합으로 쉽게 전환할 수 있다. 이를 줄여서 가상 환경 또는 venvs라고 한다.

• venv를 사용하여 Python과 설치된 패키지의 고유한 조합을 갖춘 다양한 개발 환경을 필요한 만큼 만들 수 있다.
• 각 가상 환경에 PyInstaller를 설치한다.
• PyInstaller를 사용하여 각 가상 환경에서 애플리케이션을 빌드한다.

venv를 사용할 때 PyInstaller 명령의 경로는 다음과 같다.

• Windows: ENV_ROOT\Scripts
• 기타: ENV_ROOT/bin

Windows에서 pip-Win 패키지를 사용하면 다양한 환경을 설정하고 전환하는 것이 특히 쉽다. GNU/Linux 및 macOS에서는 명령줄에서 환경을 전환한다.

Python 가상 환경에 대한 자세한 내용은 PEP 405 및 가상 환경 및 패키지에 대한 공식 Python 튜토리얼을 참조한다.

Supporting Multiple Operating Systems

If you need to distribute your application for more than one OS, for example both Windows and macOS, 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.

A File Sync & Share system like NextCloud is useful with virtual machines. Install the synchronization client in each virtual machine, all linked to your synchronization account. Keep a single copy of your script(s) in a synchronized folder. Then on any virtual machine you can run PyInstaller thus:

두 개 이상의 OS(예: Windows와 macOS 모두)에 애플리케이션을 배포해야 하는 경우 각 플랫폼에 PyInstaller를 설치하고 각 플랫폼에 앱을 별도로 번들링해야 한다.

가상화를 사용하면 단일 머신에서 이 작업을 수행할 수 있다. 무료 virtualBox 또는 유료 VMWare 및 Parallels를 사용하면 또 다른 완전한 운영 체제를 "게스트"로 실행할 수 있다. 각 "게스트" OS에 대해 가상 머신을 설정한다. 여기에서 Python, 애플리케이션에 필요한 지원 패키지 및 PyInstaller를 설치한다.

NextCloud와 같은 파일 동기화 및 공유 시스템은 가상 머신에 유용한다. 동기화 계정에 연결된 각 가상 머신에 동기화 클라이언트를 설치한다. 동기화된 폴더에 스크립트의 단일 복사본을 보관한다. 그런 다음 모든 가상 머신에서 다음과 같이 PyInstaller를 실행할 수 있다.

cd ~/NextCloud/project_folder/src # GNU/Linux, Mac -- Windows similar
rm *.pyc # get rid of modules compiled by another Python
pyinstaller --workpath=path-to-local-temp-folder  \
            --distpath=path-to-local-dist-folder  \
            ...other options as required...       \
            ./myscript.py

PyInstaller reads scripts from the common synchronized 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 GNU/Linux and macOS, 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 GNU/Linux using the free Wine environment. Further details are needed, see How to Contribute.

PyInstaller는 공통 동기화 폴더에서 스크립트를 읽지만 가상 머신의 로컬 폴더에 작업 파일과 번들 앱을 쓴다.

예를 들어 GNU/Linux 및 macOS와 같은 여러 플랫폼에서 동일한 홈 디렉터리를 공유하는 경우 각 플랫폼에서 PYINSTALLER_CONFIG_DIR 환경 변수를 다른 값으로 설정해야 한다. 그렇지 않으면 PyInstaller가 한 플랫폼에 대해 파일을 캐시하고 다른 플랫폼에서 사용할 수 있다. 기본적으로 홈 디렉터리의 하위 디렉터리를 캐시 위치로 사용한다.

무료 Wine 환경을 이용하면 GNU/Linux 환경에서도 Windows용 크로스 개발이 가능하다고 한다. 더 자세한 내용이 필요하다면 기여 방법을 참조한다.

Capturing Windows Version Data

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:

Windows 앱에는 버전 리소스 파일이 필요할 수 있다. 버전 리소스에는 실행 파일의 속성을 설명하는 데이터 구조 그룹이 포함되어 있으며 일부는 이진 정수를 포함하고 일부는 문자열을 포함한다. 자세한 내용은 Microsoft 버전 정보 구조 페이지를 참조한다.

버전 리소스는 복잡하며 일부 요소는 선택 사항이고 다른 요소는 필수이다. 속성 대화 상자의 버전 탭을 볼 때 표시되는 데이터와 리소스 구조 사이에는 단순한 관계가 없다. 이러한 이유로 PyInstaller에는 pyi-grab_version 명령이 포함되어 있다. 버전 리소스가 있는 Windows 실행 파일의 전체 경로 이름으로 호출된다.

pyi-grab_version executable_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:

이 명령은 읽을 수 있는 형식으로 버전 리소스를 나타내는 텍스트를 표준 출력에 기록한다. 콘솔 창에서 복사하거나 파일로 리디렉션할 수 있다. 그런 다음 버전 정보를 편집하여 프로그램에 맞게 조정할 수 있다. pyi-grab_version을 사용하면 원하는 종류의 정보를 표시하는 실행 파일을 찾고, 해당 리소스 데이터를 복사하고, 패키지에 맞게 수정할 수 있다.

버전 텍스트 파일은 UTF-8로 인코딩되며 ASCII가 아닌 문자를 포함할 수 있다. (버전 리소스 문자열 필드에는 유니코드 문자가 허용된다.) ASCII 문자열 값만 포함되어 있다고 확신하지 않는 한 텍스트 파일을 UTF-8로 편집하고 저장해야 한다.

편집된 버전 텍스트 파일은 --version-file 옵션을 사용하여 pyinstaller 또는 pyi-makespec에 제공할 수 있다. 텍스트 데이터는 버전 리소스로 변환되어 번들 앱에 설치된다.

버전 리소스에는 FileVersion 및 ProductVersion이라는 두 개의 64비트 이진 값이 있다. 버전 텍스트 파일에서 이는 4개 요소로 구성된 튜플로 제공된다. 예를 들면 다음과 같다.

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 pyi-set_version command:

각 튜플의 요소는 최상위부터 최하위까지 16비트 값을 나타낸다. 예를 들어 값 (2, 0, 4, 0)은 16진수로 0002000000040000으로 확인된다.

번들 앱이 생성된 후 pyi-set_version 명령을 사용하여 텍스트 파일에서 버전 리소스를 설치할 수도 있다.

pyi-set_version version_text_file executable_file

The pyi-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.

pyi-set_version 유틸리티는 pyi-grab_version이 작성한 버전 텍스트 파일을 읽고 이를 버전 리소스로 변환한 다음 지정된 실행 파일에 해당 리소스를 설치한다.

고급 사용을 위해서는 pyi-grab_version에 의해 작성된 버전 텍스트 파일을 검사한다. VSVersionInfo 개체를 생성하는 것은 Python 코드이다. VSVersionInfo에 대한 클래스 정의는 PyInstaller 배포 폴더의 utils/win32/versioninfo.py에 있다. versioninfo를 가져오는 프로그램을 작성할 수 있다. 해당 프로그램에서는 버전 정보 텍스트 파일의 내용을 평가하여 VSVersionInfo 개체를 생성할 수 있다. 해당 객체의 .toRaw() 메서드를 사용하여 버전 리소스를 바이너리 형식으로 생성할 수 있다. 또는 객체에 unicode() 함수를 적용하여 버전 텍스트 파일을 재현할 수도 있다.

Building macOS App Bundles

Under macOS, PyInstaller always builds a UNIX executable in dist. If you specify --onedir, the output is a folder named myscript containing supporting files and an executable named myscript. If you specify --onefile, the output is a single UNIX executable named myscript. Either executable can be started from a Terminal command line. Standard input and output work as normal through that Terminal window.

If you specify --windowed with either option, the dist folder also contains a macOS app bundle named myscript.app.

macOS에서 PyInstaller는 항상 dist에 UNIX 실행 파일을 빌드한다. --onedir을 지정하면 지원 파일과 myscript라는 실행 파일이 포함된 myscript라는 폴더가 출력된다. --onefile을 지정하면 출력은 myscript라는 단일 UNIX 실행 파일이다. 두 실행 파일 모두 터미널 명령줄에서 시작할 수 있다. 표준 입력 및 출력은 해당 터미널 창을 통해 정상적으로 작동한다.

두 옵션 중 하나와 함께 --windowed를 지정하면 dist 폴더에 myscript.app이라는 macOS 앱 번들도 포함된다.

Note

Generating app bundles with onefile executables (i.e., using the combination of --onefile and --windowed options), while possible, is not recommended. Such app bundles are inefficient, because they require unpacking on each run (and the unpacked content might be scanned by the OS each time). Furthermore, onefile executables will not work when signed/notarized with sandbox enabled (which is a requirement for distribution of apps through Mac App Store).

onefile 실행 파일(예: --onefile 및 --windowed 옵션 조합 사용)로 앱 번들을 생성하는 것은 가능하지만 권장되지 않는다. 이러한 앱 번들은 실행할 때마다 압축을 풀어야 하기 때문에 비효율적이다(그리고 압축이 풀린 콘텐츠는 매번 OS에서 검사할 수 있다). 또한 샌드박스가 활성화된 상태에서 서명/공증된 경우(Mac App Store를 통한 앱 배포에 대한 요구 사항) onefile 실행 파일이 작동하지 않다.

As you are likely aware, an app bundle is a special type of folder. The one built by PyInstaller always contains a folder named Contents, which contains:

• A file named Info.plist that describes the app.
• A folder named MacOS that contains the program executable.
• A folder named Frameworks that contains the collected binaries (shared libraries, python extensions) and nested .framework bundles. It also contains symbolic links to data files and directories from the Resources directory.
• A folder named Resources that contains the icon file and all collected data files. It also contains symbolic links to binaries and directories from the Resources directory.

아시다시피 앱 번들은 특별한 유형의 폴더이다. PyInstaller로 만든 폴더에는 항상 다음을 포함하는 Contents라는 폴더가 포함된다.

• 앱을 설명하는 Info.plist라는 파일.
• 프로그램 실행 파일이 포함된 MacOS라는 폴더.
• 수집된 바이너리(공유 라이브러리, Python 확장) 및 중첩된 .framework 번들을 포함하는 Frameworks라는 폴더. 또한 Resources 디렉터리의 데이터 파일 및 디렉터리에 대한 기호 링크도 포함되어 있다.
• 아이콘 파일과 수집된 모든 데이터 파일이 포함된 Resources라는 폴더. 또한 Resources 디렉터리의 바이너리 및 디렉터리에 대한 기호 링크도 포함되어 있다.

Note

The contents of the Frameworks and Resources directories are cross-linked between the two directories in an effort to maintain an illusion of a single content directory (which is required by some packages), while also trying to satisfy the Apple’s file placement requirements for codesigning.

Frameworks 및 Resources 디렉터리의 콘텐츠는 단일 콘텐츠 디렉터리(일부 패키지에서 필요함)라는 환상을 유지하는 동시에 공동 설계를 위한 Apple의 파일 배치 요구 사항을 충족시키려는 노력의 일환으로 두 디렉터리 간에 상호 연결된다.

Use the --icon argument to specify a custom icon for the application. It will be copied into the Resources folder. (If you do not specify an icon file, PyInstaller supplies a file icon-windowed.icns with the PyInstaller logo.)

Use the --osx-bundle-identifier argument to add a bundle identifier. This becomes the CFBundleIdentifier used in code-signing (see the PyInstaller code signing recipe and for more detail, the Apple code signing overview technical note).

You can add other items to the Info.plist by editing the spec file; see Spec File Options for a macOS Bundle below.

애플리케이션에 대한 사용자 정의 아이콘을 지정하려면 --icon 인수를 사용한다. Resources 폴더에 복사된다. (아이콘 파일을 지정하지 않으면 PyInstaller는 PyInstaller 로고와 함께 icon-windowed.icns 파일을 제공한다.)

--osx-bundle-identifier 인수를 사용하여 번들 식별자를 추가한다. 이는 코드 서명에 사용되는 CFBundleIdentifier가 된다(PyInstaller 코드 서명 레시피 및 자세한 내용은 Apple 코드 서명 개요 기술 노트 참조).

사양 파일을 편집하여 Info.plist에 다른 항목을 추가할 수 있다. 아래의 macOS 번들에 대한 사양 파일 옵션을 참조한다.

Platform-specific Notes

GNU/Linux

Making GNU/Linux Apps Forward-Compatible

Under GNU/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 GNU/Linux, it may fail to execute (typically with a runtime dynamic link error) if it is executed on an older version of GNU/Linux.

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

The GNU/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.

Note that PyInstaller does bundle other shared libraries that are discovered via dependency analysis, such as libstdc++.so.6, libfontconfig.so.1, libfreetype.so.6. These libraries may be required on systems where older (and thus incompatible) versions of these libraries are available. On the other hand, the bundled libraries may cause issues when trying to load a system-provided shared library that is linked against a newer version of the system-provided library.

For example, system-installed mesa DRI drivers (e.g., radeonsi_dri.so) depend on the system-provided version of libstdc++.so.6. If the frozen application bundles an older version of libstdc++.so.6 (as collected from the build system), this will likely cause missing symbol errors and prevent the DRI drivers from loading. In this case, the bundled libstdc++.so.6 should be removed. However, this may not work on a different distribution that provides libstdc++.so.6 older than the one from the build system; in that case, the bundled version should be kept, because the system-provided version may lack the symbols required by other collected binaries that depend on libstdc++.so.6.

GNU/Linux에서 PyInstaller는 앱과 함께 libc(C 표준 라이브러리, 일반적으로 glibc, Gnu 버전)를 번들로 제공하지 않다. 대신 앱은 앱이 실행되는 로컬 OS에서 libc에 동적으로 연결될 것으로 예상한다. 모든 앱과 libc 사이의 인터페이스는 최신 릴리스와 호환되지만 이전 릴리스와는 하위 호환되지 않다.

이러한 이유로 현재 버전의 GNU/Linux에서 앱을 번들로 묶는 경우 이전 버전의 GNU/Linux에서 실행되면 실행에 실패할 수 있다(일반적으로 런타임 동적 링크 오류와 함께).

해결책은 항상 지원하려는 GNU/Linux의 가장 오래된 버전에서 앱을 빌드하는 것이다. 최신 버전에 있는 libc에서는 계속 작동해야 한다.

glibc와 같은 GNU/Linux 표준 라이브러리는 64비트 및 32비트 버전으로 배포되며 이들은 호환되지 않는다. 결과적으로 앱을 32비트 시스템에 번들로 묶어서 64비트 설치에서 실행할 수 없으며 그 반대의 경우도 마찬가지이다. 지원되는 각 단어 길이에 대해 고유한 앱 버전을 만들어야 한다.

PyInstaller는 libstdc++.so.6, libfontconfig.so.1, libfreetype.so.6과 같은 종속성 분석을 통해 발견된 다른 공유 라이브러리를 번들로 묶는다. 이러한 라이브러리는 이전 버전(따라서 호환되지 않는 버전)을 사용할 수 있는 시스템에 필요할 수 있다. 반면, 번들 라이브러리는 최신 버전의 시스템 제공 라이브러리에 연결된 시스템 제공 공유 라이브러리를 로드하려고 할 때 문제를 일으킬 수 있다.

예를 들어, 시스템에 설치된 메사 DRI 드라이버(예: radeonsi_dri.so)는 시스템에서 제공하는 libstdc++.so.6 버전에 따라 달라진다. 고정된 애플리케이션이 이전 버전의 libstdc++.so.6(빌드 시스템에서 수집된 대로)을 번들로 묶는 경우 기호 누락 오류가 발생하고 DRI 드라이버가 로드되지 않을 수 있다. 이 경우 번들로 제공되는 libstdc++.so.6을 제거해야 한다. 그러나 이는 빌드 시스템의 것보다 오래된 libstdc++.so.6을 제공하는 다른 배포판에서는 작동하지 않을 수 있다. 이 경우 시스템 제공 버전에는 libstdc++.so.6에 의존하는 다른 수집 바이너리에 필요한 기호가 부족할 수 있으므로 번들 버전을 유지해야 한다.

Windows

The developer needs to take special care to include the Visual C++ run-time .dlls: Python 3.5+ uses Visual Studio 2015 run-time, which has been renamed into “Universal CRT“ and has become part of Windows 10. For Windows Vista through Windows 8.1 there are Windows Update packages, which may or may not be installed in the target-system. So you have the following options:

1. Build on Windows 7 which has been reported to work.

1. Include one of the VCRedist packages (the redistributable package files) into your application’s installer. This is Microsoft’s recommended way, see “Distributing Software that uses the Universal CRT“ in the above-mentioned link, numbers 2 and 3.

1. Install the Windows Software Development Kit (SDK) for Windows 10 and expand the .spec-file to include the required DLLs, see “Distributing Software that uses the Universal CRT“ in the above-mentioned link, number 6.

If you think, PyInstaller should do this by itself, please help improving PyInstaller.

개발자는 Visual C++ 런타임 .dll을 포함하기 위해 특별한 주의를 기울여야 한다. Python 3.5+는 "Universal CRT"로 이름이 바뀌고 Windows 10의 일부가 된 Visual Studio 2015 런타임을 사용한다. Windows Vista의 경우 Windows 8.1에는 대상 시스템에 설치되거나 설치되지 않을 수 있는 Windows 업데이트 패키지가 있다. 따라서 다음과 같은 옵션이 있다.

1. 작동하는 것으로 보고된 Windows 7에서 빌드한다.

1. VCRedist 패키지(재배포 가능 패키지 파일) 중 하나를 애플리케이션 설치 프로그램에 포함한다. 이는 Microsoft에서 권장하는 방법이다. 위에서 언급한 링크의 2번과 3번에서 "Universal CRT를 사용하는 소프트웨어 배포"를 참조한다.

1. Windows 10용 Windows 소프트웨어 개발 키트(SDK)를 설치하고 필요한 DLL을 포함하도록 .spec 파일을 확장한다. 위에서 언급한 링크 6번에서 "유니버설 CRT를 사용하는 소프트웨어 배포"를 참조한다.

PyInstaller가 이 작업을 스스로 수행해야 한다고 생각한다면 PyInstaller 개선에 도움을 바란다.

macOS

Making macOS apps Forward-Compatible

On macOS, system components from one version of the OS are usually compatible with later versions, but they may not work with earlier versions. While PyInstaller does not collect system components of the OS, the collected 3rd party binaries (e.g., python extension modules) are built against specific version of the OS libraries, and may or may not support older OS versions.

As such, the only way to ensure that your frozen application supports an older version of the OS is to freeze it on the oldest version of the OS that you wish to support. This applies especially when building with Homebrew python, as its binaries usually explicitly target the running OS.

For example, to ensure compatibility with “Mojave” (10.14) and later versions, you should set up a full environment (i.e., install python, PyInstaller, your application’s code, and all its dependencies) in a copy of macOS 10.14, using a virtual machine if necessary. Then use PyInstaller to freeze your application in that environment; the generated frozen application should be compatible with that and later versions of macOS.

macOS에서 한 OS 버전의 시스템 구성 요소는 일반적으로 이후 버전과 호환되지만 이전 버전에서는 작동하지 않을 수 있다. PyInstaller는 OS의 시스템 구성 요소를 수집하지 않지만 수집된 타사 바이너리(예: Python 확장 모듈)는 특정 버전의 OS 라이브러리에 대해 구축되며 이전 OS 버전을 지원할 수도 있고 지원하지 않을 수도 있다.

따라서 고정된 응용 프로그램이 이전 버전의 OS를 지원하는지 확인하는 유일한 방법은 지원하려는 OS의 가장 오래된 버전에서 응용 프로그램을 고정하는 것이다. 이는 특히 Homebrew Python으로 빌드할 때 적용된다. 바이너리는 일반적으로 실행 중인 OS를 명시적으로 대상으로 하기 때문이다.

예를 들어 "Mojave"(10.14) 및 이후 버전과의 호환성을 보장하려면 다음을 사용하여 macOS 10.14 복사본에 전체 환경(예: Python, PyInstaller, 애플리케이션 코드 및 모든 종속 항목 설치)을 설정해야 한다. 필요한 경우 가상 머신. 그런 다음 PyInstaller를 사용하여 해당 환경에서 애플리케이션을 고정한다. 생성된 고정 애플리케이션은 해당 버전 및 이후 버전의 macOS와 호환되어야 한다.

Building 32-bit Apps in macOS

Note

This section is largely obsolete, as support for 32-bit application was removed in macOS 10.15 Catalina (for 64-bit multi-arch support on modern versions of macOS, see here). However, PyInstaller still supports building 32-bit bootloader, and 32-bit/64-bit Python installers are still available from python.org for (some) versions of Python 3.7 which PyInstaller dropped support for in v6.0.

이 섹션은 macOS 10.15 Catalina에서 32비트 애플리케이션에 대한 지원이 제거되었기 때문에 대부분 더 이상 사용되지 않는다(최신 macOS 버전의 64비트 멀티 아키텍처 지원은 여기 참조). 그러나 PyInstaller는 여전히 32비트 부트로더 빌드를 지원하며, PyInstaller가 v6.0에서 지원을 중단한 Python 3.7의 (일부) 버전에 대해 32비트/64비트 Python 설치 프로그램을 python.org에서 계속 사용할 수 있다.

Older versions of macOS 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.

To verify that the installed python version supports execution in either 64- or 32-bit mode, use the file command on the Python executable:

이전 버전의 macOS는 32비트 및 64비트 실행 파일을 모두 지원했다. PyInstaller는 앱을 실행하는 데 사용된 Python의 단어 길이를 사용하여 앱을 빌드한다. 이는 일반적으로 64비트 버전의 Python이므로 64비트 실행 파일이 생성된다. 32비트 실행 파일을 만들려면 32비트 Python에서 PyInstaller를 실행하라.

설치된 Python 버전이 64비트 또는 32비트 모드에서 실행을 지원하는지 확인하려면 Python 실행 파일에서 file 명령을 사용한다.

$ file /usr/local/bin/python3
/usr/local/bin/python3: Mach-O universal binary with 2 architectures
/usr/local/bin/python3 (for architecture i386):     Mach-O executable i386
/usr/local/bin/python3 (for architecture x86_64):   Mach-O 64-bit executable x86_64

The OS chooses which architecture to run, and typically defaults to 64-bit. You can force the use of either architecture by name using the arch command:

OS는 실행할 아키텍처를 선택하며 일반적으로 기본값은 64비트이다. arch 명령을 사용하여 두 아키텍처 중 하나를 이름으로 강제로 사용할 수 있다.

$ /usr/local/bin/python3
Python 3.7.6 (v3.7.6:43364a7ae0, Dec 18 2019, 14:12:53)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.maxsize
9223372036854775807

$ arch -i386 /usr/local/bin/python3
Python 3.7.6 (v3.7.6:43364a7ae0, Dec 18 2019, 14:12:53)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.maxsize
2147483647

Note

PyInstaller does not provide pre-built 32-bit bootloaders for macOS anymore. In order to use PyInstaller with 32-bit python, you need to build the bootloader yourself, using an XCode version that still supports compiling 32-bit. Depending on the compiler/toolchain, you may also need to explicitly pass --target-arch=32bit to the waf command.

PyInstaller는 더 이상 macOS용으로 사전 구축된 32비트 부트로더를 제공하지 않는다. 32비트 Python과 함께 PyInstaller를 사용하려면 여전히 32비트 컴파일을 지원하는 XCode 버전을 사용하여 부트로더를 직접 빌드해야 한다. 컴파일러/툴체인에 따라 --target-arch=32bit를 waf 명령에 명시적으로 전달해야 할 수도 있다.

Getting the Opened Document Names

When user double-clicks a document of a type that is registered with your application, or when a user drags a document and drops it on your application’s icon, macOS launches your application and provides the name(s) of the opened document(s) in the form of an OpenDocument AppleEvent.

These events are typically handled via installed event handlers in your application (e.g., using Carbon API via ctypes, or using facilities provided by UI toolkits, such as tkinter or PyQt5).

Alternatively, PyInstaller also supports conversion of open document/URL events into arguments that are appended to sys.argv. This applies only to events received during application launch, i.e., before your frozen code is started. To handle events that are dispatched while your application is already running, you need to set up corresponding event handlers.

For details, see this section.

사용자가 응용 프로그램에 등록된 유형의 문서를 두 번 클릭하거나 문서를 끌어서 응용 프로그램 아이콘에 놓으면 macOS는 응용 프로그램을 시작하고 열린 문서의 이름을 제공한다. OpenDocument AppleEvent 형식이다.

이러한 이벤트는 일반적으로 애플리케이션에 설치된 이벤트 핸들러를 통해 처리된다(예: ctypes를 통해 Carbon API 사용 또는 tkinter 또는 PyQt5와 같은 UI 도구 키트에서 제공하는 기능 사용).

또는 PyInstaller는 열린 문서/URL 이벤트를 sys.argv에 추가되는 인수로 변환하는 것도 지원한다. 이는 애플리케이션 실행 중, 즉 고정된 코드가 시작되기 전 수신된 이벤트에만 적용된다. 애플리케이션이 이미 실행 중인 동안 전달된 이벤트를 처리하려면 해당 이벤트 핸들러를 설정해야 한다.

자세한 내용은 이 섹션을 참조한다.

AIX

Depending on whether Python was build as a 32-bit or a 64-bit executable you may need to set or unset the environment variable OBJECT_MODE. To determine the size the following command can be used:

Python이 32비트 또는 64비트 실행 파일로 빌드되었는지 여부에 따라 환경 변수 OBJECT_MODE를 설정하거나 설정 해제해야 할 수도 있다. 크기를 결정하려면 다음 명령을 사용할 수 있다.

$ python -c "import sys; print(sys.maxsize <= 2**32)"
True

When the answer is True (as above) Python was build as a 32-bit executable.

When working with a 32-bit Python executable proceed as follows:

대답이 True인 경우(위와 같이) Python은 32비트 실행 파일로 빌드되었다.

32비트 Python 실행 파일로 작업하는 경우 다음을 수행한다.

$ unset OBJECT_MODE
$ pyinstaller 

When working with a 64-bit Python executable proceed as follows:

64비트 Python 실행 파일로 작업하는 경우 다음을 수행한다.

$ export OBJECT_MODE=64
$ pyinstaller