Admin

name	type	size	perms	modified	actions
[parent directory]
distutils/	dir	-	0755	2026-08-19 08:34:12
changed_keywords.rst	file	2,177 B	0644	2023-12-23 15:08:45	edit
commands.rst	file	29,674 B	0644	2023-12-23 15:08:45	edit
dependency_links.rst	file	2,859 B	0644	2023-12-23 15:08:45	edit
distutils-legacy.rst	file	2,433 B	0644	2023-12-23 15:08:45	edit
easy_install.rst	file	52,010 B	0644	2023-12-23 15:08:45	edit
functionalities.rst	file	1,451 B	0644	2023-12-23 15:08:45	edit
index.rst	file	863 B	0644	2023-12-23 15:08:45	edit
python_eggs.rst	file	30,943 B	0644	2023-12-23 15:08:45	edit
resource_extraction.rst	file	3,047 B	0644	2023-12-23 15:08:45	edit
zip_safe.rst	file	3,649 B	0644	2023-12-23 15:08:45	edit

editing: resource_extraction.rst

.. _Automatic Resource Extraction:

Automatic Resource Extraction
=============================

In a modern setup, Python packages are usually installed as directories,
and all the files can be found on deterministic locations on the disk.
This means that most of the tools expect package resources to be "real" files.

There are a few occasions however that packages are loaded in a different way
(e.g., from a zip file), which is incompatible with the assumptions mentioned above.
Moreover, a package developer may also include non-extension native libraries or other files that
C extensions may expect to be able to access.

In these scenarios, the use of :mod:`importlib.resources` is recommended.

Old implementations (prior to the advent of :mod:`importlib.resources`) and
long-living projects, however, may still rely on the library ``pkg_resources``
to access these files.

If you have to support such systems, or want to provide backward compatibility
for ``pkg_resources``, you may need to add an special configuration
to ``setuptools`` when packaging a project.
This can be done by listing as ``eager_resources`` (argument to ``setup()``
in ``setup.py`` or field in ``setup.cfg``) all the files that need to be
extracted together, whenever a C extension in the project is imported.

This is especially important if your project includes shared libraries *other*
than ``distutils``/``setuptools``-built C extensions, and those shared libraries use file
extensions other than ``.dll``, ``.so``, or ``.dylib``, which are the
extensions that setuptools 0.6a8 and higher automatically detects as shared
libraries and adds to the ``native_libs.txt`` file for you.  Any shared
libraries whose names do not end with one of those extensions should be listed
as ``eager_resources``, because they need to be present in the filesystem when
he C extensions that link to them are used.

The ``pkg_resources`` runtime for compressed packages will automatically
extract *all* C extensions and ``eager_resources`` at the same time, whenever
*any* C extension or eager resource is requested via the ``resource_filename()``
API.  (C extensions are imported using ``resource_filename()`` internally.)
This ensures that C extensions will see all of the "real" files that they
expect to see.

Note also that you can list directory resource names in ``eager_resources`` as
well, in which case the directory's contents (including subdirectories) will be
extracted whenever any C extension or eager resource is requested.

Please note that if you're not sure whether you need to use this argument, you
don't!  It's really intended to support projects with lots of non-Python
dependencies and as a last resort for crufty projects that can't otherwise
handle being compressed.  If your package is pure Python, Python plus data
files, or Python plus C, you really don't need this.  You've got to be using
either C or an external program that needs "real" files in your project before
there's any possibility of ``eager_resources`` being relevant to your project.

cancel