When building a Python binary, there are various settings that control which Python resources are added, where they are imported from, and other various settings. This collection of settings is referred to as a Python Packaging Policy. These settings are represented by the PythonPackagingPolicy type.


The following sections describe the attributes available on each instance.



Whether to allow loading of Python extension modules and shared libraries from memory at run-time.

Some platforms (notably Windows) allow opening shared libraries from a memory address. This mode of opening shared libraries allows libraries to be embedded in binaries without having to statically link them. However, not every library works correctly when loaded this way.

This flag defines whether to enable this feature where supported. Its true value can be ignored if the target platform doesn’t support loading shared library from memory.



Whether to add Python bytecode at optimization level 0 (the default optimization level the Python interpreter compiles bytecode for).



Whether to add Python bytecode at optimization level 1.



Whether to add Python bytecode at optimization level 2.



The filter to apply to determine which extension modules to add. The following values are recognized:

Every named extension module will be included.
Return only extension modules that are required to initialize a Python interpreter. This is a very small set and various functionality from the Python standard library will not work with this value.

Return only extension modules that don’t require any additional libraries.

Most common Python extension modules are included. Extension modules like _ssl (links against OpenSSL) and zlib are not included.


Return only extension modules that do not link against GPL licensed libraries.

Not all Python distributions may annotate license info for all extensions or the libraries they link against. If license info is missing, the extension is not included because it could be GPL licensed. Similarly, the mechanism for determining whether a license is GPL is based on an explicit list of non-GPL licenses. This ensures new GPL licenses don’t slip through.

Default is all.



Whether to add source code for Python modules in the Python distribution.

Default is True.



Whether to add Python package resources for Python packages in the Python distribution.

Default is False.



Whether to add source code for Python modules not in the Python distribution.



Whether to add Python resources related to tests.

Not all files associated with tests may be properly flagged as such. This is a best effort setting.

Default is False.



The location that resources should be added to by default.

Default is in-memory.

(string or None)

The fallback location that resources should be added to if resources_location fails.

Default is None.


(dict<string, string>) (readonly)

Mapping of extension module name to variant name.

This mapping defines which preferred named variant of an extension module to use. Some Python distributions offer multiple variants of the same extension module. This mapping allows defining which variant of which extension to use when choosing among them.

Keys set on this dict are not reflected in the underlying policy. To set a key, call the set_preferred_extension_module_variant() method.


The following sections describe methods on PythonPackagingPolicy instances.


This method registers a Starlark function to be called when resource objects are created. The passed function receives 2 arguments: this PythonPackagingPolicy instance and the resource (e.g. PythonModuleSource) that was created.

The purpose of the callback is to enable Starlark configuration files to mutate resources upon creation so they can globally influence how those resources are packaged.


This method will set a preferred Python extension module variant to use. See the documentation for preferred_extension_module_variants above for more.

It accepts 2 string arguments defining the extension module name and its preferred variant.