Packaging python for windows

Packaging desktop app

Flet Python app and all its dependencies can be packaged into an executable and user can run it on their computer without installing a Python interpreter or any modules.

Flet wraps PyInstaller API to package Flet Python app and all its dependencies into a single package for Windows, macOS and Linux. To create Windows package, PyInstaller must be run on Windows; to build Linux app, it must be run on Linux; and to build macOS app — on macOS.

Start from installing PyInstaller:

Navigate to the directory where your .py file is located and build your app with the following command:

Your bundled Flet app should now be available in dist folder. Try running the program to see if it works.

Now you can just zip the contents of dist folder and distribute to your users! They don’t need Python or Flet installed to run your packaged program — what a great alternative to Electron!

By default, an executable/bundle has the same name as a Python script. You can change it with —name argument:

flet pack your_program.py --name bundle_name 

Customizing package icon​

Default bundle app icon is diskette which might be confusing for younger developers missed those ancient times when floppy disks were used to store computer data.

You can replace the icon with your own by adding —icon argument:

flet pack your_program.py --icon 

PyInstaller will convert provided PNG to a platform specific format ( .ico for Windows and .icns for macOS), but you need to install Pillow module for that:

Packaging assets​

Your Flet app can include assets. Provided app assets are in assets folder next to your_program.py they can be added to an application package with —add-data argument, on macOS/Linux:

flet pack your_program.py --add-data "assets:assets" 

On Windows assets;assets must be delimited with ; :

flet pack your_program.py --add-data "assets;assets" 

Customizing macOS bundle​

macOS bundle details can be customized with the following flet pack macOS-specific arguments:

• —product-name — display name of macOS bundle, shown in Dock, Activity Monitor, About dialog.
• —product-version — bundle version shown in «About» dialog.
• —copyright — copyright notice shown in «About» dialog.
• —bundle-id unique bundle ID.

Customizing Windows executable metadata​

Windows executable «Details» properties dialog can be customized with the following flet pack arguments:

• —product-name — «Product name» field.
• —product-version — «Product version» field.
• —file-version — «File version» field.
• —file-description — «File description» field, also program display name in Task Manager.
• —copyright — «Copyright» field.

Using CI for multi-platform packaging​

To create an app package with PyInstaller for specific OS it must be run on that OS.

If you don’t have an access to Mac or PC you can bundle your app for all three platforms with AppVeyor — Continuous Integration service for Windows, Linux and macOS. In short, Continuous Integration (CI) is an automated process of building, testing and deploying (Continuous Delivery — CD) application on every push to a repository.

AppVeyor is free for open source projects hosted on GitHub, GitLab and Bitbucket. To use AppVeyor, push your app to a repository within one of those source-control providers.

AppVeyor is the company behind Flet.

To get started with AppVeyor sign up for a free account.

Click «New project» button, authorize AppVeyor to access your GitHub, GitLab or Bitbucket account, choose a repository with your program and create a new project.

Now, to configure packaging of your app for Windows, Linux and macOS, add file with the following contents into the root of your repository appveyor.yml . appveyor.yml is a build configuration file, or CI workflow, describing build, test, packaging and deploy commands that must be run on every commit.

You can just fork flet-dev/python-ci-example repository and customize it to your needs.

When you push any changes to GitHub repository, AppVeyor will automatically start a new build:

What that CI workflow does on every push to the repository:

• Clones the repository to a clean virtual machine.
• Installs app dependencies using pip .
• Runs flet pack to package Python app into a bundle for Windows, macOS and Ubuntu.
• Zip/Tar app bundles and uploads them to «Artifacts».
• Uploads app bundles to GitHub releases when a new tag is pushed. Just push a new tag to make a release!

GITHUB_TOKEN in appveyor.yml is a GitHub Personal Access Token (PAT) used by AppVeyor to publish created packages to repository «Releases». You need to generate your own token and replace it in appveyor.yml . Login to your GitHub account and navigate to Personal access token page. Click «Generate new token» and select «public_repo» or «repo» scope for public or private repository respectively. Copy generated token to a clipboard and return to AppVeyor Portal. Navigate to Encrypt configuration data page and paste token to «Value to encrypt» field, click «Encrypt» button. Put encrypted value under GITHUB_TOKEN in your appveyor.yml .

Configure AppVeyor for your Python project, push a new tag to a repository and «automagically» get desktop bundle for all three platforms in GitHub releases! 🎉

In addition to GitHub Releases, you can also configure releasing of artifacts to Amazon S3 bucket or Azure Blob storage.

Источник

Installing Packages¶

This section covers the basics of how to install Python packages .

It’s important to note that the term “package” in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a distribution ). It does not to refer to the kind of package that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a distribution using the term “package”. Using the term “distribution” is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself.

Requirements for Installing Packages¶

This section describes the steps to follow before installing other Python packages.

Ensure you can run Python from the command line¶

Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:

You should get some output like Python 3.6.3 . If you do not have Python, please install the latest 3.x version from python.org or refer to the Installing Python section of the Hitchhiker’s Guide to Python.

If you’re a newcomer and you get an error like this:

>>> python3 --version Traceback (most recent call last): File "", line 1, in NameError: name 'python3' is not defined 

It’s because this command and other suggested commands in this tutorial are intended to be run in a shell (also called a terminal or console). See the Python for Beginners getting started tutorial for an introduction to using your operating system’s shell and interacting with Python.

If you’re using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ! character:

In [1]: import sys ! --version Python 3.6.3

It’s recommended to write rather than plain python in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the python command refers to).

Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the python command in this tutorial with python3 and the python -m pip command with python3 -m pip —user . Do not run any of the commands in this tutorial with sudo : if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written.

Ensure you can run pip from the command line¶

Additionally, you’ll need to make sure you have pip available. You can check this by running:

If you installed Python from source, with an installer from python.org, or via Homebrew you should already have pip. If you’re on Linux and installed using your OS package manager, you may have to install pip separately, see Installing pip/setuptools/wheel with Linux Package Managers .

If pip isn’t already installed, then first try to bootstrap it from the standard library:

python3 -m ensurepip --default-pip

py -m ensurepip --default-pip

If that still doesn’t allow you to run python -m pip :

• Securely Download get-pip.py1
• Run python get-pip.py . 2 This will install or upgrade pip. Additionally, it will install setuptools and wheel if they’re not installed already.

Warning Be cautious if you’re using a Python install that’s managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use python get-pip.py —prefix=/usr/local/ to install in /usr/local which is designed for locally-installed software.

Ensure pip, setuptools, and wheel are up to date¶

While pip alone is sufficient to install from pre-built binary archives, up to date copies of the setuptools and wheel projects are useful to ensure you can also install from source archives:

python3 -m pip install --upgrade pip setuptools wheel

py -m pip install --upgrade pip setuptools wheel

Optionally, create a virtual environment¶

See section below for details, but here’s the basic venv 3 command to use on a typical Linux system:

python3 -m venv tutorial_env source tutorial_env/bin/activate

py -m venv tutorial_env tutorial_env\Scripts\activate

This will create a new virtual environment in the tutorial_env subdirectory, and configure the current shell to use it as the default python environment.

Creating Virtual Environments¶

Python “Virtual Environments” allow Python packages to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see Installing stand alone command line tools .

Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can’t install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments.

Currently, there are two common tools for creating Python virtual environments:

• venv is available by default in Python 3.3 and later, and installs pip and setuptools into created virtual environments in Python 3.4 and later.
• virtualenv needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and pip , setuptools and wheel are always installed into created virtual environments by default (regardless of Python version).

The basic usage is like so:

python3 -m venv source /bin/activate

Источник