PythonEggs |
UserPreferences |
The PEAK Developers' Center | FrontPage | RecentChanges | TitleIndex | WordIndex | SiteNavigation | HelpContents |
"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:
There are also other benefits that may come from having a standardized format, similar to the benefits of Java's "jar" format.
If you have a pure-Python egg that doesn't use any in-package data files, and you don't mind manually placing it on sys.path or PYTHONPATH, you can use the egg without installing setuptools. For eggs containg C extensions, however, or those that need access to non-Python data files contained in the egg, you'll need the pkg_resources module from setuptools installed. You can do this either by installing setuptools, or by copying the pkg_resources module to an appropriate directory.
In addition to providing runtime support for using eggs containing C extensions or data files, the pkg_resources module also provides an API for automatically locating eggs and their dependencies and adding them to sys.path at runtime. With this support, you can install and keep multiple versions of the same package on your system, with the right version automatically being selected at runtime. Plus, if an egg has a dependency that can't be met, the runtime will raise a DistributionNotFound error that says what package and version is needed.
By the way, in case you're wondering how you can tell a "pure" (all-Python) egg from one with C extensions, the difference is that eggs containing C extensions will have their target platform's name at the end of the filename, just before the .egg. "Pure" eggs are (in principle) platform-indepenent, and have no platform name. If you're using the pkg_resources runtime to find eggs for you, it will ignore any eggs that it can tell are not usable on your platform or Python version. If you're not using the runtime, you'll have to make sure that you use only compatible eggs.
Once you have the runtime installed, you need to get your desired egg(s) on to sys.path. You can do this manually, by placing them in the PYTHONPATH environment variable, or you can add them directly to sys.path in code. This approach doesn't scale well, however, because as you need additional eggs, you'll be managing a longer and longer PYTHONPATH or sys.path by hand. Not only that, but you'll have to manually keep track of all the eggs needed by the eggs you're using! Luckily, there is a better way to do it.
The better way to manage your eggs is to place them in a directory that's already on sys.path, such as site-packages, or the directory that your application's main script is in, or a directory that you'll be adding to PYTHONPATH or sys.path. Then, before attempting to import from any eggs, use a snippet of code like this:
from pkg_resources import require require("FooBar>=1.2")
This will search all sys.path directories for an egg named "FooBar" whose release version is 1.2 or higher, and it will automatically add the newest matching version to sys.path for you, along with any eggs that the FooBar egg needs. (A note about versions: the egg runtime system understands typical version numbering schemes, so it knows that versions like "1.2a1" and "1.2rc5" are actually older than the plain version "1.2", but it also knows that versions like "1.2p1" or "1.2-1" are newer than "1.2".)
You can specify more than one requirement when calling require(), and you can also specify more complex version requirements, like require("FooBar>=1.2", "Thingy>1.0,!=1.5,<2.0a3,==2.1,>=2.3"). Requirement strings basically consist of a distribution name, an optional list of "options" (more on this in a moment), and a comma-separated list of zero or more version conditions. Version conditions basically specify ranges of valid versions, using comparison operators. The version conditions you supply are sorted into ascending version order, and then scanned left to right until the package's version falls between a pair of > or >= and < or <= conditions, or exactly matches a == or != condition.
Note, by the way, that it's perfectly valid to have no version conditions; if you can use any version of "FooBar", for example, you can just require("FooBar"). Distribution names are also case-insensitive, so require("foobar") would also work, but for clarity's sake we recommend using the same spelling as the package's author.
Some eggs may also offer "options" - optional features that, if used, will need other eggs to be located and added to sys.path. You can specify zero or more options that you wish to use, by placing a comma-separated list in square brackets just after the requested distribution name. For example, the "FooBarWeb" web framework might offer optional FastCGI support. When you require("FooBarWeb[FastCGI]>=1.0"), the additional eggs needed to support the FastCGI option will also be added to sys.path. (Or, if one of them isn't found, a pkg_resources.DistributionNotFound error will be raised, identifying what dependency couldn't be satisfied.)
To find out what options an egg offers, you should consult its documentation, or unpack and read its EGG-INFO/depends.txt file, which lists an egg's required and optional dependencies. For more on the format of depends.txt, see the Declaring Dependencies section below.
(Note: the pkg_resources module does not automatically look for eggs on PyPI or download them from anywhere; any needed eggs must already be available in a directory on sys.path, or require() will raise a DependencyNotFound error. You can of course trap this error in your code and attempt to find the needed eggs on PyPI or elsewhere. But, if you want your application to support automated downloads, a better approach is to create a subclass of the AvailableDistributions class in pkg_resources and override its obtain() method to do the desired searching and downloading. See the source code of the require() function for how to use an AvailableDistributions object to resolve dependencies.)
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 sandbox and run setup.py install to install it (assuming you haven't already installed it in order to use the pkg_resources runtime). 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. ("SomePackage" will of course be replacd by the name of the package you're building.) Any files placed in this directory are copied to an EGG-INFO directory within the egg file, for use at runtime. There are a handful of special filenames that the egg runtime system understands, like eager_resources.txt and depends.txt, both of which we'll cover in a moment. Other metadata files are automatically generated for you, such as native_libs.txt (a list of C extensions, if any) and PKG-INFO (descriptive information about the package). Do not edit these files, as the next time you run bdist_egg they will be overwritten with the automatically generated versions.
If you want to build eggs from other people's packages (who don't import from setuptools), then in Python 2.4 and higher you can do:
python setup.py --command-packages=setuptools.command bdist_egg
If you're using Python 2.3, however (and eggs don't work with versions less than 2.3), you have to copy setuptools/command/bdist_egg.py into the distutils/command/ directory of your Python installation (e.g. in lib/python2.3 or \Python23\Lib).
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__. (TODO: forward reference here to API intro section under Developing Eggs)
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.)
Some eggs need other eggs to function. However, there isn't always a meaningful place for a library to call require(), and in any case a library's source code is rarely the place to declare its version dependencies. So setuptools allows you to create a depends.txt file that can be bundled inside the .egg file's metadata directory, and which will be used by the egg runtime to automatically locate the egg's dependencies and add them to sys.path whenever the egg is needed by a require() call.
To create this file, you'll need to place it in the SomePackage.egg-info directory that the bdist_egg command creates. The format is fairly simple; here's a heavily-commented example:
# A sample "MyPackageName.egg-info/depends.txt" file # Blank lines and lines beginning with "#" are ignored # Lines at the beginning of the file specify the package's minimum # requirements, and line-end comments are allowed: FooBar >= 1.2 # a 'require()'-style dependency # Here, we specify a more restricted set of versions for another # package -- just the ones we've tested with this package. Notice # that if a requirement is too long to fit on a line, you can use "\" # to continue it, as long as the split is between version conditions. # Notice also that arbitrary whitespace is allowed between tokens: BazSpam ==1.1, ==1.2, ==1.3, ==1.4, ==1.5, \ ==1.6, ==1.7 [FastCGI] # A line with a name in square brackets defines an "option" # The lines that follow, specify what other eggs are needed # if this optional feature is requested. fcgiapp>=0.1 FastCGITools>=2.1 [reST] # Here's another optional feature: reStructuredText processing. We # need docutils to support that. docutils >= 0.3
Of course, you don't have to comment your dependencies and features so thoroughly or use so much whitespace if you don't want to. Here's a minimal rendering of the same example, with exactly the same semantics:
FooBar>=1.2 BazSpam==1.1,==1.2,==1.3,==1.4,==1.5,==1.6,==1.7 [FastCGI] fcgiapp>=0.1 FastCGITools>=2.1 [reST] docutils>=0.3
But, as you can see, a little whitespace and commenting goes a long way towards other people understanding what your dependencies are. At the least, a blank line before option definitions makes them easier to find and read.
Currently, the depends.txt file is not syntax-checked by bdist_egg, so if you make a mistake you won't find out about it until you try to use the egg. (This will be fixed in a later version.)
TODO: explain how to use SomePackage.egg-info dirs to work with packages that are already on sys.path/PYTHONPATH
TODO: introduce pkg_resources APIs for accessing data files
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.
The following API routines will be available in the pkg_resources module as module-level functions:
These need name, version, python version, and a metadata API, as well as PEP 302 "importer" methods.
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)
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.)
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.
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
This method returns the loaded module.
See: PEP 302 Loader Protocol