The PEAK Developers' Center   PythonEggs UserPreferences
 
HelpContents Search Diffs Info Edit Subscribe XML Print View
Version as of 2005-05-23 21:25:10

Clear message


Python Eggs

Overview

"Eggs are to Pythons as Jars are to Java..."

Python Eggs are zipfiles using the .egg extension, that support including data and C extensions as well as Python code. They can be used with Python 2.3 and up, and can be built using the setuptools package (see http://cvs.sf.net/viewcvs.py/python/python/nondist/sandbox/setuptools/ for source code). Once the implementation is far enough along, we plan to propose it for inclusion with the standard library beginning in Python 2.5.

The primary benefits of Python Eggs are:

  • They are a "zero installation" format for a Python package; no build or install step is required, just put them on PYTHONPATH or sys.path and use them
  • They can include package metadata, such as the other eggs they depend on
  • They allow "namespace packages" (packages that just contain other packages) to be split into separate distributions (e.g. zope.*, twisted.*, peak.* packages can be distributed as separate eggs, unlike normal packages which must always be placed under the same parent directory. This allows what are now huge monolithic packages to be distributed as separate components.)
  • They allow applications or libraries to specify the needed version of a library, so that you can e.g. require("Twisted-Internet>=2.0") before doing an import twisted.internet.

There are also other benefits that may come from having a standardized format, similar to the benefits of Java's "jar" format.

Using Eggs

To use an egg, simply put its absolute filename in your PYTHONPATH environment variable, or add it to sys.path. That's all. For "pure" (all-Python) eggs, it's just like putting Java .jar files on CLASSPATH.

Some eggs, however, may contain C extensions or need access to non-Python data files contained in the egg. These eggs also need to have access to the pkg_resources module in order to be able to unpack any needed files (like C extensions). So, you need to also make sure you have a setuptools egg on your path for the other egg(s) to work. (See Building Eggs below.)

Note also that only "pure" (all-Python) eggs are platform-independent. Eggs that contain C extensions will have their target platform's name at the end of the filename, just before the .egg, and you will need to make sure that you only use eggs that are appropriate for your platform.

(Note: we are working on a "dependency/discovery" API that will allow programs to automatically find suitable .egg files within specified directories, and recursively find eggs to meet the requested eggs' dependencies. So, in future it should be as simple as pkg_resources.require("SomePackage>=1.2") in order to locate an appropriate .egg and add it to sys.path automatically.)

Building Eggs

To build an egg from a package's setup.py, you'll need to have setuptools installed. Just check it out of Python's CVS and run setup.py install to install it. Now you're ready to build eggs.

Edit the target package's setup.py and add from setuptools import setup such that it replaces the existing import of the setup function. Then run setup.py bdist_egg.

That's it. A .egg file will be deposited in the dist directory, ready for use. If you want to add any special metadata files, you can do so in the SomePackage.egg-info directory that bdist_egg creates. There are a handful of special filenames that the egg runtime system understands, like eager_resources.txt, and in the future there will be others to support namespace packages, dependency resolution, etc. These files are copied from the .egg-info directory to an EGG-INFO directory within the egg file, for use by the runtime.

If you want to build eggs from other people's packages (who don't import from setuptools) in Python 2.4 you can do:

python setup.py --command-packages=setuptools.command bdist_egg

In earlier versions of Python you have to copy setuptools/command/bdist_egg.py into lib/pythonX.Y/distutils/command/. This is known to work for Python 2.3.

Note: packages that expect to find data files in their package directories, but which do not use either the PEP 302 API or the pkg_resources API to find them will not work when packaged as .egg files. One way you can check for this is if the .egg file contains data files, and the package is using __file__ to find them. You'll need to then patch the package so it uses pkg_resources.resource_filename() or one of the other resource_* APIs instead of __file__.

Also, some packages (e.g. wxPython) may include dynamic link libraries other than Python extensions. If this is the case, you'll need to create an eager_resources.txt file in the .egg-info directory that lists the in-zip paths to these libraries, one per line. This will let the runtime system know that those files need to be unpacked if any of the extensions are used. Thus, when attempting to import an extension, the runtime will also unpack all the dynamic link libraries that go with it.

(Note: if you still can't get the library to work as an .egg file after trying the above tactics, please report your problem on the distutils-Sig mailing list. Thanks.)

Implementation Status

Egg Builder (bdist_egg command)
  • (DONE) format suitable for use with zipimport if no resource access (including extensions) is needed
  • (DONE) add required EGG-INFO metadata directory for storing info about the egg itself
  • (DONE) include PKG-INFO metadata file in the EGG-INFO
  • (DONE) Hand-made EGG-INFO files can be placed in an PackageName.egg-info directory of the distribution
  • (DONE) By default, all .so/.dll/.pyd files are "eager" (listed in EGG-INFO/native_libs.txt)
  • (DONE) build process generates .py/.pyc/.pyo stubs to load extensions via pkg_resources.resource_filename() calls
  • Need a way to specify features to be excluded from egg distribution
  • needs option to not include source code in .egg (default is to include source, for IDE's, debugging, etc.)
Resource Manager Open Issues
  • (DONE) Egg-info can include list of "eager resources" which must be extracted all-at-once if any of them are extracted (listed in EGG-INFO/eager_resources.txt)
  • Cleanup on Windows doesn't work, because the .pyd's remain in use as long as Python is still running. An application that really wants to clean up on exit can presumably spawn another process to do something about it, but that kind of sucks. (Michael Dubner suggested using HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\FileRenameOperations to fix the Windows problem, but unfortunately didn't give any details or sample code.)
  • Default cache location: os.expanduser() is broken on Windows, as it can result in a directory that isn't actually writable. May need to use registry info to fix this, or default to a temporary directory on Windows. At least an application can choose a fixed location if it wants to ensure future executions will be fast. (Unix home directories aren't necessarily writable either, so maybe a temporary directory really is the right default, or perhaps try to create the home first and fall back to a temporary if the directory isn't writable.)
  • The extraction process needs to be protected by a thread lock and a process lock (i.e., prevent collisions both inside and outside the current process)
  • The extract process treats the file's timestamp in the zipfile as "local" time with "unknown" DST. It's theoretically possible that a DST change could cause the system to think that the file timestamp no longer matches the zip timestamp. Also, the resulting Unix-style timestamp for the extracted file may differ between systems with different timezones. This is an unfortunate side effect of the fact that the zip file format does not include timezone information or a UTC timestamp.
  • Fix home directory location on Windows
  • Allow listing or globbing of resources, or unpacking resource directories (rather than just individual files, which are all that's currently supported).
Namespace Packages
  • Need to implement hook in Distribution.install_on() to fix up existing NS packages, and to flag namespace packages identified from distribution metadata (e.g. EGG-INFO/namespace_packages.txt).
  • Need namespace_package() API in pkg_resources
Dependency/Discovery
  • (DONE) Given a sys.path entry, iterate over available distributions, either .egg directories, .egg files, or distributions identified by .egg-info directories.
  • (DONE) Version spec syntax (needs to support specifying "extras" in order to implement optional dependencies)
  • (DONE) require() API call to automatically resolve dependencies and add them to sys.path
  • (DONE) EGG-INFO.in/depends.txt (feature->requirements mapping specifying distribution+version)
  • Add support for extending the distribution finder for non-filesystem sys.path entries (by adapting PEP 302 importer objects)

Older Stuff

The stuff from here on down is fairly out of date; it's just here to make sure we didn't forget anything once the current runtime refactoring is complete.

Package Resource API

The following API routines will be available in the pkg_resources module as module-level functions:

declare_namespace(name)
Declare that the dotted package name name is a "namespace package" whose contained packages and modules may be spread across multiple distributions. The named package's __path__ will be extended to include the corresponding package in all active distributions that contain a package of that name. (More precisely, if an importer's find_module(name) returns a loader, then it will also be searched for the package's contents.) Whenever a Distribution's require() is invoked, it checks for the presence of namespace packages and updates their __path__ contents accordingly. A distribution is "active" if its require() has been invoked, or if it is present on sys.path.
iter_distributions(name=None,path=None)
Searching the list of locations specified by path, yield Distribution instances whose names match name. If name is None, all recognized distributions are yielded. If path is None, the resource manager's default path is searched. If the resource manager has no default path, sys.path is searched. Distribution objects yielded by this routine may be added to sys.metapath in order to make them accessible for importing, as they are PEP 302-compatible "importer" objects.
require(name,version_info=None,path=None)
Ensure that the named distribution (matching version_info if specified) is present on sys.meta_path. The path argument is the same as for iter_distributions(). XXX define version-info format!
resource_string(package_name,resource_name)
Return the named resource as a binary string.
resource_stream(package_name,resource_name,mode='b')
Open the named resource as a file-like object, using the specified mode ('t', 'b', or 'U'). (Note that this does not necessarily return an actual file; if you need a fileno() or an actual operating system file, you should use resource_filename() instead.)
resource_filename(package_name,resource_name)
Return a platform file or directory name for the named resource. If the package is in an egg distribution, the resource will be unpacked before the filename is returned. If the named resource is a directory, the entire directory's contents will be extracted before the directory name is returned. Also, if the named resource is an "eager" resource such as a Python extension or shared library, then all "eager" resources will be extracted before the resource's filename is returned. (This is to ensure that shared libraries that link to other included libraries will have their dependencies available before loading.)
set_extraction_path(path)
Set the base path where resources will be extracted to. If not set, this defaults to os.expanduser("~/.python-eggs"). Resources are extracted to subdirectories of this path, named for the corresponding .egg file. You may set this to a temporary directory, but then you must call cleanup_resources() to delete the extracted files when done. (Note: you may not change the extraction path for a given resource manager once resources have been extracted, unless you first call cleanup_resources().)
cleanup_resources(force=False)
Delete all extracted resource files and directories, returning a list of the file and directory names that could not be successfully removed. This function does not have any concurrency protection, so it should generally only be called when the extraction path is a temporary directory exclusive to a single process. This method is not automatically called; you must call it explicitly or register it as an atexit function if you wish to ensure cleanup of a temporary directory used for extractions.

Distribution Objects

These need name, version, python version, and a metadata API, as well as PEP 302 "importer" methods.

require()
Add an appropriate entry to the beginning of sys.meta_path for this Distribution if not present.
get_platform_info()
Return the platform information for this Distribution as a str or None if not present.
get_version_object()
Return the version information for this Distribution as a distutils.version StrictVersion or LooseVersion or None if not present.
get_python_version()
Return the Python version for this Distribution as a str containing the major Python version (i.e. "2.3") or None if not present.
get_name()
Return the name of this Distribution without any platform or version information.
get_archive_name()
Return the name of this Distribution with all platform and version information.
get_distdata(filename, default=NotGiven)
Like PEP 302's get_data, this returns the data for the specified path. This may be used to retrieve distribution metadata (such as EGG-INFO/native_libs.txt). Unlike PEP 302, this method permits you to specify a default value to be returned if the resource is not present in the distribution archive. This is for convenience in retrieving optional metadata files, such as are contained in archives' EGG-INFO files.
get_resource_path(module, package_name, resource_name)

For a module that this Distribution controls, return the path for the given resource. Typically implemented as:

return os.path.join(os.path.dirname(module.__file__), resource_name)
get_resource_stream(module, package_name, resource_name, mode='rb')

Open the path as a file-like object, using the specified mode ('t', 'b', or 'U').

(Note that this does not necessarily return an actual file; if you need a fileno() or an actual operating system file, you should use get_filename() instead.)

get_resource_filename(module, package_name, resource_name)

Return an openable file or directory path for the given filename. If the filename is not already on the filesystem, it will be extracted to a file allocated by the ResourceManager. If the filename represents a directory, the ResourceManager will allocate files for the entire tree.

The Distribution may allocate more files than requested during this call. A trivial implementation could extract the entire archive's contents, and a complex implementation may decide to extract all object code at the same time (e.g. dll, pyd, so, etc.). Resources that are extracted before they are requested are termed "eager" resources.

get_resource_string(module, package_name, resource_name)
Return the named resource as a binary string.
find_module(fullname, path=None)

This method will be called with the fully qualified name of the module. If the importer is installed on sys.meta_path, it will receive a second argument, which is None for a top-level module, or package.__path__ for submodules or subpackages. It should return a loader object if the module was found, or None if it wasn't. If find_module() raises an exception, it will be propagated to the caller, aborting the import.

See: PEP 302 Importer Protocol

load_module(fullname)

This method returns the loaded module.

See: PEP 302 Loader Protocol

is_package(fullname)
See: PEP 302 Optional Extensions to the Importer Protocol
get_code(fullname)
See: PEP 302 Optional Extensions to the Importer Protocol
get_source(fullname)
See: PEP 302 Optional Extensions to the Importer Protocol
get_data(filename)
See: PEP 302 Optional Extensions to the Importer Protocol

PythonPowered
EditText of this page (last modified 2005-05-23 21:25:10)
FindPage by browsing, title search , text search or an index
Or try one of these actions: AttachFile, DeletePage, LikePages, LocalSiteMap, SpellCheck