- Guidelines for Python Egg packaging
- Contents
- Why Eggs
- When to Provide Egg Metadata
- Upstream Egg Packages
- Providing Egg Metadata Using Setuptools
- Multiple Versions
- Egg «Features» to avoid
- Links
- Python .Egg Files: What are They and How to Create Egg Files?
- Difference between wheel and egg files
- Python Egg File Formats
- Prerequisites for Creating Egg Files
- Creating a Python .egg file
- Conclusion
Guidelines for Python Egg packaging
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. See https://src.fedoraproject.org/rpms/pyproject-rpm-macros for packaging wheels instead.
Contents
Python packages provide extra metadata about the package in the form of egg metadata. This document explains how to package those metadata.
Why Eggs
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. See https://src.fedoraproject.org/rpms/pyproject-rpm-macros for packaging wheels instead.
Egg metadata have several uses including:
- Allowing end users to install egg packages not made from rpms or install egg packages into their home directories. This is an important feature for people working within a shared hosting environment.
- Giving python packages an easy way to support plugins.
- Giving us a way to support multiple versions of a python module for compat libraries.
The egg metadata can be used at runtime so they cannot be replaced with the rpm database which is only useful at install time or by tools specifically for Fedora.
When to Provide Egg Metadata
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. See https://src.fedoraproject.org/rpms/pyproject-rpm-macros for packaging wheels instead.
When upstream uses setuptools to provide egg metadata it will be automatically built and installed when you use the %py_build and %py_install macros.
Upstream Egg Packages
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. See https://src.fedoraproject.org/rpms/pyproject-rpm-macros for packaging wheels instead.
Do not distribute egg packages from upstream. In Fedora, all packages must be rebuilt from source. An egg package (which is different from egg metadata) contains compiled bytecode and may, if it contains a C extension, contain compiled binary extensions as well. These are opaque structures with no guarantee that they were even built from the source distributed with the egg. If you must use an egg package from upstream because they do not provide tarballs, you need to include it as a source in your spec, unzip it in %setup, and rebuild from the source files contained within it.
Providing Egg Metadata Using Setuptools
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. See https://src.fedoraproject.org/rpms/pyproject-rpm-macros for packaging wheels instead.
When upstream uses setuptools to provide egg metadata it is very simple to include them in your package. Your spec file will look something like this:
# Must have setuptools to build the package BuildRequires: python2-setuptools [. ] %install %py2_install [. ] %files [. ] # This captures both the module directory and the egg-info directory # Something like: # /usr/lib/python2.7/site-packages/sqlalchemy # /usr/lib/python2.7/site-packages/SQLAlchemy-0.3.10-py2.7.egg-info %/sqlalchemy/ %/*egg-info/
Multiple Versions
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. Package multiple conflicting versions of the package instead.
Sometimes we want to keep an old version of a module around for compatibility. When upstream has renamed the module for us, this is a straightforward creation of a new module. For instance, python-psycopg and python-psycopg2.
When upstream doesn’t include the version in the name, we have to find another way to parallel install two versions of the package. Egg metadata give us this ability. The latest version of a package must be installed as the python-MODULENAME and is built using the normal guidelines. The compatibility versions of the module should be named python-$MODULENAME$DISTINGUISHINGVER and be enabled by making these spec file changes:
# Require setuptools as the consumer will need pkg_resources to use this module Requires: python2-setuptools %build # Build an egg file that we can then install from %py2_build_egg %install # Install the egg so that only code that wants this particular version can get it. %py2_install_egg
This creates the python egg under the %/*.egg directory. This module is not directly usable via the import statement. Instead, the consuming package must setup the PYTHONPATH to reference the compat version before it imports the module. This can be done in a variety of ways.
- Manually modifying sys.path is quick if the user just wants to try out some code with the old version:
>>> import sys >>> sys.path.insert(0, '/usr/lib/python2.7/site-packages/CherryPy-2.2.1-py2.7.egg/') >>> import cherrypy
- Using setuptools and easy_install to create «script wrappers» to invoke the programs. Setuptools has you define an entrypoint in the program’s module (basically, a main() function) and then writes a script to access that via an option in setup.py.
It is highly recommended that any such compatibility packages install a README.fedora file explaining how to use this module. The file should contain the above examples of how to call the module from code and explain that this is a compat package and that a newer version exists.
There are several other methods of invoking scripts so that they might take the right version but they suffer from various problems. They are listed here because a program you’re packaging may use them and you need to know about them if they break. If you mention them in README.fedora, please also add why they are dangerous to use.
- pkg_resources.requires(‘MODULE[VERSIONINFO] ‘) : Does not work with a default version (able to be imported via import MODULE). The setuptools author refuses to remove this limitation and refuses to document that it is a limitation. Therefore you may run across scripts that use this method and need to patch them to use one of the above, supported methods instead.
- __requires__=’MODULE[VERSIONINFO] ‘ : This works but the setuptools author feels that it is only a workaround and will not support it. It works presently but could stop in a future version of setuptools. Some upstreams use this method and may need to be fixed if the setuptools author ever changes the interface.
Egg «Features» to avoid
Old page
This page is very very old. The information on this page is not accurate. Don’t package eggs. See https://src.fedoraproject.org/rpms/pyproject-rpm-macros for packaging wheels instead.
Egg metadata provide some features that are to be avoided as part of the packaging process for Fedora. Some of these may provide benefit to our users but should not be used when creating system packages.
- Do not let easy_install download and install packages from the net to add to the build root. This will fail on the build system as well as being bad packaging. Packages which are downloaded are probably missing from your BuildRequires.
Links
- https://src.fedoraproject.org/rpms/pyproject-rpm-macros
- http://peak.telecommunity.com/DevCenter/PythonEggs
- http://peak.telecommunity.com/DevCenter/setuptools
- http://lists.debian.org/debian-python/2007/09/msg00004.html — Discussion of eggs in Debian
- http://mail.python.org/pipermail/distutils-sig/2007-September/008181.html — Discussion of these guidelines on the distutils list
Copyright © 2023 Red Hat, Inc. and others. All Rights Reserved. For comments or queries, please contact us.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content.
- This page was last edited on 26 March 2021, at 11:31.
- Content is available under Attribution-Share Alike 4.0 International unless otherwise noted.
- Privacy policy
- About Fedora Project Wiki
- Disclaimers
- Code of Conduct
- Sponsors
- Legal
- Trademark Guidelines
Python .Egg Files: What are They and How to Create Egg Files?
Python egg is an older version of the Python wheel package containing the metadata and installation information about a particular python package. It is usually present as a .zip file, composed of logical information, resources and source code of a python module or library.
A python egg can be physically encoded but it has been superseded by the python wheel package. Nowadays, python eggs are replaced by python wheel packages which perform the same functions.
Difference between wheel and egg files
Before pip install and wheel packages, .egg files were used for installing and uninstalling python packages from local systems.
As of 2023, Python egg files have completely been replaced by wheel files which have a more defined and structured method of storing metadata and installation resources of python files.
Wheel is a distribution format used for making installations for python. On the other hand, the egg format was both a runtime as well as a distribution package. These files were importable which is unlike python wheel packages.
Wheel packages have an official binary package called the official PyPA specifications, containing a list of all active interrelated specifications. This specification package was preceded by the .PEP 427 official support page.
Python Egg File Formats
Python currently supports three different versions of the egg file format.
- .egg format: This is the file that contains the metadata and source code of a package.
- .egg-info format: This file contains the metadata of the project located adjacent to the .egg file.
- .egg-link format : This file is occasionally encountered which is only used to make a reference to a .egg file. This is not an actual file, it just points to the .egg file. They came into existence to make cross platform alternative to links.
Even though .egg format is not used anymore in the newer versions of python, instead , wheel files are used for setup. But regardless we can still create and use egg files in older versions of python by using the setuptools and build modules.
Prerequisites for Creating Egg Files
In order to use the modules, namely, setuptools and build you will need to install them in your system.
The setuptools package helps in easy installation/uninstallation of python tools. It also makes setting up of modules easier and faster. We can also upgrade existing packages with this.
The build module helps in configuring local command line code and in smooth running of commands. You can easily switch between different projects using this module. These tools are only accessible through the project directory.
We will also use the find_packages() function from setuptools.
Now, we have to run the following code to install these two packages in our system.
pip install setuptools pip install 1build
Creating a Python .egg file
Running the code below will create an .egg file for us:
# importing the required modules from setuptools import setup, find_packages #creating a setup file setup( name = "ourfile", version = "0.1", packages = find_packages() )
Now, we have to run the following in the terminal:
After running the above code in the terminal, you should ideally see that there are three new folders that will be created namely,
Note: For many systems, this might give an error because the most widely used distribution package is wheels for the newer versions of python. It is recommended to use wheel files for newer installations and avoid .egg files since they are obsolete as of now.
Conclusion
The .egg format is suited for easy package installation and also used for upgrading existing modules. It is basically a .zip file that is an older version of the python wheel file . Nowadays, python eggs are obsolete, so it is advisable to create python wheel files so they can be easily used for the newer versions of python. Creating egg files can also raise errors due to version mismatch. To know more about python eggs, visit the official python archive.