The syntax of the pyinstaller command is:
To automate this process for Windows, add a single command line that includes the installer option REGISTER='1'. The installer runs -register and registers the product. To register Tableau from the command line, you need to prefill the registry (Windows) or.plist (Mac) values on each computer that will run Tableau Desktop and Tableau Prep Builder. In this how-to I'll show you how to launch an OS X app from the command line with the open command. Note: A little bit of prior UNIX experience will be helpful here. First off, I will admit this. Oct 09, 2018 Successful execution would open the app on a simulator or a connected device. For this to happen, there are a bunch of steps which are executed when we run the above command. Run-ios command. React-Native provides a number of command line utilities to work with the app. These can be found under the local-cli folder of the React-Native node module.
pyinstaller [options] script [script …] | specfileIn the most simple case,set the current directory to the location of your program myscript.pyand execute:
PyInstaller analyzes myscript.py and:
- Writes
myscript.specin the same folder as the script. - Creates a folder
buildin the same folder as the script if it does not exist. - Writes some log files and working files in the
buildfolder. - Creates a folder
distin the same folder as the script if it does not exist. - Writes the
myscriptexecutable folder in thedistfolder.
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 thespec 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:
pyinstallermyscript.specThe myscript.spec file contains most of the informationprovided by the options that were specified whenpyinstaller (or pyi-makespec)was run with the script file as the argument.You typically do not need to specify any options when runningpyinstaller with the spec file.Only a few command-line optionshave an effect when building from a spec file.
You may give a path to the script or spec file, for example
or, on Windows,
pyinstaller'C:DocumentsandSettingsprojectmyscript.spec'Options¶
General 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) |
| --workpath WORKPATH | |
| Where to put all the temporary work files, .log, .pyzand etc. (default: ./build) | |
| -y, --noconfirm | |
| Replace output directory (default:SPECPATH/dist/SPECNAME) without asking forconfirmation | |
| --upx-dir UPX_DIR | |
| Path to UPX utility (default: search the executionpath) | |
| -a, --ascii | Do not include unicode encoding support (default:included if available) |
| --clean | Clean PyInstaller cache and remove temporary filesbefore building. |
| --log-level LEVEL | |
| Amount of detail in build-time console messages. LEVELmay be one of TRACE, DEBUG, INFO, WARN, ERROR,CRITICAL (default: INFO). | |
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) | |
What to bundle, where to search¶
| --add-data <SRC;DEST or SRC:DEST> | |
Additional non-binary files or folders to be added tothe executable. The path separator is platformspecific, os.pathsep (which is ; on Windowsand : on most unix systems) is used. This optioncan be used multiple times. | |
| --add-binary <SRC;DEST or SRC:DEST> | |
Additional binary files to be added to the executable.See the --add-data option for more details. Thisoption can be used multiple times. | |
| -p DIR, --paths DIR | |
| A path to search for imports (like using PYTHONPATH).Multiple paths are allowed, separated by ‘:’, or usethis option multiple times | |
| --hidden-import MODULENAME, --hiddenimport MODULENAME | |
| Name an import not visible in the code of thescript(s). This option can be used multiple times. | |
| --additional-hooks-dir HOOKSPATH | |
| An additional path to search for hooks. This optioncan be used multiple times. | |
| --runtime-hook RUNTIME_HOOKS | |
| Path to a custom runtime hook file. A runtime hook iscode that is bundled with the executable and isexecuted before any other code or module to set upspecial features of the runtime environment. Thisoption can be used multiple times. | |
| --exclude-module EXCLUDES | |
| Optional module or package (the Python name, not thepath name) that will be ignored (as though it was notfound). This option can be used multiple times. | |
| --key KEY | The key used to encrypt Python bytecode. |
How to generate¶
| -d <all,imports,bootloader,noarchive>, --debug <all,imports,bootloader,noarchive> | |
Provide assistance with debugging a frozenapplication. This argument may be provided multipletimes to select several of the following options.
| |
| -s, --strip | Apply a symbol-table strip to the executable andshared libs (not recommended for Windows) |
| --noupx | Do not use UPX even if it is available (worksdifferently between Windows and *nix) |
| --upx-exclude FILE | |
| Prevent a binary from being compressed when using upx.This is typically used if upx corrupts certainbinaries during compression. FILE is the filename ofthe binary without path. This option can be usedmultiple times. | |
Windows and Mac OS X specific options¶
| -c, --console, --nowindowed | |
| Open a console window for standard i/o (default). OnWindows this option will have no effect if the firstscript is a ‘.pyw’ file. | |
| -w, --windowed, --noconsole | |
| Windows and Mac OS X: do not provide a console windowfor standard i/o. On Mac OS X this also triggersbuilding an OS X .app bundle. On Windows this optionwill be set if the first script is a ‘.pyw’ file. Thisoption is ignored in *NIX systems. | |
| -i <FILE.ico or FILE.exe,ID or FILE.icns>, --icon <FILE.ico or FILE.exe,ID or FILE.icns> | |
| FILE.ico: apply that 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 OSX | |
Windows specific options¶
| --version-file FILE | |
| add a version resource from FILE to the exe | |
| -m <FILE or XML>, --manifest <FILE or XML> | |
| add manifest FILE or XML to the exe | |
| -r RESOURCE, --resource RESOURCE | |
| Add or update a resource to a Windows executable. TheRESOURCE is one to four items,FILE[,TYPE[,NAME[,LANGUAGE]]]. FILE can be a data fileor an exe/dll. For data files, at least TYPE and NAMEmust be specified. LANGUAGE defaults to 0 or may bespecified as wildcard * to update all resources of thegiven TYPE and NAME. For exe/dll files, all resourcesfrom FILE will be added/updated to the finalexecutable if TYPE, NAME and LANGUAGE are omitted orspecified as wildcard *.This option can be usedmultiple times. | |
| --uac-admin | Using this option creates a Manifest which willrequest elevation upon application restart. |
| --uac-uiaccess | Using this option allows an elevated application towork with Remote Desktop. |
Windows Side-by-side Assembly searching options (advanced)¶
| --win-private-assemblies | |
| Any Shared Assemblies bundled into the applicationwill be changed into Private Assemblies. This meansthe exact versions of these assemblies will always beused, and any newer versions installed on usermachines at the system level will be ignored. | |
| --win-no-prefer-redirects | |
| While searching for Shared or Private Assemblies tobundle into the application, PyInstaller will prefernot to follow policies that redirect to newerversions, and will try to bundle the exact versions ofthe assembly. | |
Mac OS X specific options¶
| --osx-bundle-identifier BUNDLE_IDENTIFIER | |
| Mac OS X .app bundle identifier is used as the defaultunique program name for code signing purposes. Theusual form is a hierarchical name in reverse DNSnotation. For example:com.mycompany.department.appname (default: firstscript’s basename) | |
Rarely used special options¶
| --runtime-tmpdir PATH | |
Where to extract libraries and support files inonefile-mode. If this option is given, thebootloader will ignore any temp-folder locationdefined by the run-time OS. The _MEIxxxxxx-folderwill be created here. Please use this option only ifyou know what you are doing. | |
| --bootloader-ignore-signals | |
| Tell the bootloader to ignore signals rather thanforwarding them to the child process. Useful insituations where e.g. a supervisor process signalsboth the bootloader and child (e.g. via a processgroup) to avoid signalling the child twice. | |
Shortening the Command¶
Because of its numerous options, a full pyinstaller commandcan become very long.You will run the same command again and again as you developyour 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:
Or in Windows, use the little-known BAT file line continuation:
Running PyInstaller from Python code¶
If you want to run PyInstaller from within Python code use the runfunction of the __main__ module and pass all command line arguments in asa list, e.g.
Running PyInstaller with Python optimizations¶
Note
When using this feature, you should be aware of how the Python bytecodeoptimization mechanism works. When using -O, __debug__ is setto False and assert statements are removed from the bytecode.The -OO flag additionally removes docstrings.
Using this feature affects not only your main script, but all modulesincluded by PyInstaller. If your code (or any module imported by yourscript) relies on these features, your program may break or haveunexpected behavior.
PyInstaller can be run with Python optimization flags (-O or -OO)by executing it as a Python module, rather than using the pyinstallercommand:
Or, by explicitly setting the PYTHONOPTIMIZE environment variableto a non-zero value:
You can use any PyInstaller options that are otherwise available withthe pyinstaller command. For example:
Alternatively, you can also use the path to pyinstaller:
Using UPX¶
UPX is a free utility available for most operating systems.UPX compresses executable files and libraries, making them smaller,sometimes much smaller.UPX is available for most operating systems and can compressa large number of executable file formats.See the UPX home page for downloads, and for the list ofsupported executable formats.
Update Chrome Mac Command Line
A compressed executable program is wrapped in UPXstartup code that dynamically decompresses the programwhen the program is launched.After it has been decompressed, the program runs normally.In the case of a PyInstaller one-file executable that hasbeen UPX-compressed, the full execution sequence is:
- The compressed program start up in the UPX decompressor code.
- After decompression, the program executes the PyInstaller bootloader,which creates a temporary environment for Python.
- The Python interpreter executes your script.
PyInstaller looks for UPX on the execution pathor the path specified with the --upx-dir option.If UPX exists, PyInstaller applies it to the final executable,unless the --noupx option was given.UPX has been used with PyInstaller output often, usually with no problems.
Encrypting Python Bytecode¶
To encrypt the Python bytecode modules stored in the bundle,pass the --key=key-string argument onthe command line.
For this to work, you must have the PyCryptomodule installed.The key-string is a string of 16 characters which is used toencrypt each file of Python byte-code before it is stored inthe archive inside the executable file.
Defining the Extraction Location¶
In rare cases, when you bundle to a single executable(see Bundling to One File and How the One-File Program Works),you may want to control the location of the temporary directory at compiletime. This can be done using the --runtime-tmpdir option. If this option isgiven, the bootloader will ignore any temp-folder location defined by therun-time OS. Please use this option only if you know what you are doing.
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 yournormal development setup.
Supporting Multiple Python Environments¶
When you need to bundle your application within one OSbut for different versions of Python and support libraries – for example,a Python 3 version and a Python 2.7 version;or a supported version that uses Qt4 and a development version that uses Qt5 –we recommend you use virtualenv.With virtualenv you can maintain different combinations of Pythonand installed packages, and switch from one combination to another easily.(If you work only with Python 3.4 and later, python3-mvenvdoes the same job, see module venv.)
Mac App Call Command Line Free
- Use virtualenv to create as many different development environments as you need,each with its unique combination of Python and installed packages.
- Install PyInstaller in each environment.
- Use PyInstaller to build your application in each environment.
Note that when using virtualenv, the path to the PyInstaller commands is:
- Windows: ENV_ROOTScripts
- Others: ENV_ROOT/bin
Under Windows, the pip-Win package installs virtualenv and makes itespecially easy to set up different environments and switch between them.Under GNU/Linux and Mac OS, you switch environments at the command line.
See PEP 405 for more information about Python virtual environments.
Supporting Multiple Operating Systems¶
If you need to distribute your application for more than one OS,for example both Windows and Mac OS X, you must install PyInstalleron 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 Parallelsallow you to run another complete operating system as a “guest”.You set up a virtual machine for each “guest” OS.In it you installPython, the support packages your application needs, and PyInstaller.
The Dropbox system is useful with virtual machines.Install a Dropbox client in each virtual machine, all linked to your Dropbox account.Keep a single copy of your script(s) in a Dropbox folder.Then on any virtual machine you can run PyInstaller thus:
PyInstaller reads scripts from the common Dropbox folder,but writes its work files and the bundled app in folders thatare local to the virtual machine.
If you share the same home directory on multiple platforms, forexample GNU/Linux and OS X, you will need to set the PYINSTALLER_CONFIG_DIRenvironment variable to different values on each platform otherwisePyInstaller may cache files for one platform and use them on the otherplatform, as by default it uses a subdirectory of your home directoryas its cache location.
It is said to be possible to cross-develop for Windows under GNU/Linuxusing the free Wine environment.Further details are needed, see How to Contribute.
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 andsome elements are optional, others required.When you view the version tab of a Properties dialog,there’s no simple relationship betweenthe 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 executablethat has a Version resource:
The command writes text that representsa 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 ofinformation 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 arecertain 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 andinstalled 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:
The elements of each tuple represent 16-bit valuesfrom most-significant to least-significant.For example the value (2,0,4,0) resolves to0002000000040000 in hex.
You can also install a Version resource from a text file afterthe bundled app has been created, using the pyi-set_version command:
pyi-set_versionversion_text_fileexecutable_fileThe pyi-set_version utility reads a version text file as writtenby 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 inutils/win32/versioninfo.py in the PyInstaller distribution folder.You can write a program that imports versioninfo.In that program you can evalthe contents of a version info text file to produce aVSVersionInfo object.You can use the .toRaw() method of that object toproduce a Version resource in binary form.Or you can apply the unicode() function to the objectto reproduce the version text file.
Building Mac OS X App Bundles¶
Under Mac OS X, PyInstaller always builds a UNIX executable indist.If you specify --onedir, the output is a folder named myscriptcontaining supporting files and an executable named myscript.If you specify --onefile, the output is a single UNIX executablenamed 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 folderalso contains an OS X application named myscript.app.
As you probably know, an application is a special type of folder.The one built by PyInstaller contains a folder always namedContents which contains:
- A folder
Frameworkswhich is empty. - A folder
Resourcesthat contains an icon file. - A file
Info.plistthat describes the app. - A folder
MacOSthat contains the the executable andsupporting files, just as in the--onedirfolder.
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 afile 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 recipeand 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 Mac OS X Bundle below.
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 thelocal OS where it runs.The interface between any app and libc is forward compatible tonewer 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) ifit is executed on an older version of GNU/Linux.
The solution is to always build your app on the oldest version ofGNU/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-bitand 32-bit versions, and these are not compatible.As a result you cannot bundle your app on a 32-bit system and run iton a 64-bit installation, nor vice-versa.You must make a unique version of the app for each word-length supported.
Windows¶
For Python >= 3.5 targeting Windows < 10, the developer needs to takespecial 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:
Build on Windows 7 which has been reported to work.
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-mentionedlink, numbers 2 and 3.
Install the Windows Software Development Kit (SDK) for Windows 10 and expand the.spec-file to include the required DLLs, see “Distributing Software thatuses the Universal CRT“ in the above-mentioned link, number 6.
If you think, PyInstaller should do this by itself, please helpimprovingPyInstaller.
Mac OS X¶
Making Mac OS X apps Forward-Compatible¶
In Mac OS X, components from one version of the OS are usually compatiblewith later versions, but they may not work with earlier versions.
The only way to be certain your app supports an older version of Mac OS Xis to run PyInstaller in the oldest version of the OS you need to support.
For example, to be sure of compatibility with “Snow Leopard” (10.6)and later versions, you should execute PyInstaller in that environment.You would create a copy of Mac OS X 10.6, typically in a virtual machine.In it, install the desired level of Python(the default Python in Snow Leopard was 2.6, which PyInstaller no longer supports),and install PyInstaller, your source, and all its dependencies.Then build your app in that environment.It should be compatible with later versions of Mac OS X.
Building 32-bit Apps in Mac OS X¶
Older versions of Mac OS X supported both 32-bit and 64-bit executables.PyInstaller builds an app using the the word-length of the Python used to execute it.That will typically be a 64-bit version of Python,resulting in a 64-bit executable.To create a 32-bit executable, run PyInstaller under a 32-bit Python.
Python as installed in OS X will usually be executable in either 64- or 32-bit mode.To verify this, apply the file command to the Python executable:
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:
Apple’s default /usr/bin/python may circumvent the archspecification and run 64-bit regardless.(That is not the case if you apply arch to a specific versionsuch as /usr/bin/python2.7.)To make sure of running 32-bit in all cases, set the following environment variable:
Getting the Opened Document Names¶
Note
Support for OpenDocument events is broken in PyInstaller 3.0owing to code changes needed in the bootloader to support currentversions of Mac OS X.Do not attempt to use this feature until it has been fixed.If this feature is important to you, follow and comment onthe status of PyInstaller Issue #1309.
When a user double-clicks a document of a type your applicationsupports, or when a user drags a document icon and drops iton your application’s icon, Mac OS X launches your applicationand provides the name(s) of the opened document(s) in theform of an OpenDocument AppleEvent.This AppleEvent is received by the bootloaderbefore your code has started executing.
The bootloader gets the names of opened documents fromthe OpenDocument event and encodes them into the argvstring before starting your code.Thus your code can query sys.argv to get the namesof documents that should be opened at startup.
OpenDocument is the only AppleEvent the bootloader handles.If you want to handle other events, or events thatare delivered after the program has launched, you mustset up the appropriate handlers.
by Soujanya PS
I recently started to develop a React-Native app on iOS. This was my first foray into native app development. I was surprised by the ease and level of abstraction provided by React-Native’s command line interface. I was also curious to understand what happens under the hood when React-Native runs an app on a device or a simulator.
I spent a lot of time going through the relevant code. There was no one place which summarized what React-Native does to get the app working. Partly, that was the motivation to come up with this piece. I want to help any other person who is starting off afresh with React-Native app development.
React-Native provides command line utilities to run an app on iOS and Andriod simulators/devices. Without further ado, let's try to understand the what and how of the process to run React-Native apps on iOS.
Behind the scenes
React-native provides this neat utility called init. It creates a native app template for you. This template creates the relevant Xcode project files under the iOS folder of the app.
React-Native apps can be launched on iOS simulators/physical devices by running the following command in the root folder of an app:
Successful execution would open the app on a simulator or a connected device. For this to happen, there are a bunch of steps which are executed when we run the above command.
run-ios command
React-Native provides a number of command line utilities to work with the app. These can be found under the local-cli folder of the React-Native node module. run-ios is one such utility which invokes the runIOS() function defined in the runIOS.js file. run-ios accepts certain options such as:
Device/Simulator selection
When no device is specified, run-ios would launch the app in Debug mode on a simulator by default. This is done by executing a series of xcrun simctl commands. They would first check the list of available simulators on Mac, pick one among them, and then boot the selected simulator.
Alternatively, if you wish to run the app on a physical device, plug the device to the Mac and then pass on the device details to the run-ios command.
The next step is to build the Xcode project of the app.
Building App code
Usually, the React-Native app Xcode project can be found in the iOS folder present under the root folder. The Xcode project is built using the xcodebuild command. Any options specified to run-ios such as the configuration etc. are passed on to this command.
By default, the Xcode project is built in Debug scheme. Once the project is successfully built, the app is installed and launched on the simulator or the connected device.
App code bundling in Debug Mode
During the development process, React Native loads our JavaScript code dynamically at runtime. For this, we need a server to bundle our app code and provide it as needed.
While the Xcode project is being built in Debug mode, an instance of Metro server is also started in parallel. Metro is the bundler used by apps created by the React-Native command line interface (CLI). It is used to bundle our app code in development. This helps us with faster and easier debugging by enabling hot reloading etc.
Metro server is configured to start on port 8081 by default. Once the app is launched in the simulator, a request is sent to the server for the bundle.
The server then downloads all the required dependencies, bundles the JavaScript app code and sends it back to the app. After this step, you can see the app working on the simulator or a connected device.
App code bundling in Release Mode — Pre-packaging the JavaScript bundle
In release mode, we have to pre-package the JavaScript bundle and distribute it inside our app. Doing this requires a code change so that it knows to load the static bundle. In AppDelegate.m file, change jsCodeLocation to point to the static bundle if you’re not in debug mode.
This will now reference the main.bundle resource file. This file is created during the Bundle React Native code and images build Phase in Xcode. During this phase, react-native-xcode.shscript is runwhich bundles the JavaScript app code. This script can be found under the React-Native node module’s scripts folder.
Building the app from Xcode
Alternatively, the Xcode project can also be built within Xcode in Mac instead of using the React-Native CLI. Once done, the app can be launched on a simulator selected from the Xcode options or on a connected physical device.
I hope this helped you understand the various steps which happen when we run a simple react-native run-ios command which magically brings up an app on iOS.
Some parts of the information provided here have been sourced from the React-Native home page. The rest is a product of me snooping around the code :)