- 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
- Saved searches
- Use saved searches to filter your results more quickly
- No .egg-info directory found for certain packages #8760
- No .egg-info directory found for certain packages #8760
- Comments
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
Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No .egg-info directory found for certain packages #8760
No .egg-info directory found for certain packages #8760
Comments
Environment
- pip version: 20.2.2
- Python version: 3.7.6 [GCC 4.4.7 20120313 (Red Hat 4.4.7-23)]
- OS: Fedora 31 (Workstation) x86_64 (kernel 5.7.11-100.fc31.x86_64
Description
Several packages (PyYAML, pylzma, bokeh) fail installation after downloading, with a cryptic ERROR: No .egg-info directory found in /dev/shm/.
Expected behavior
How to Reproduce
- Install XPLOR.
- Update pip and setuptools, install wheel: pyXplor -m pip install -U setuptools pip wheel
- Try to install PyYAML: pyXplor -m pip install -U pyyaml
$ sudo pyXplor -m pip install pyyaml Collecting pyyaml Using cached PyYAML-5.3.1.tar.gz (269 kB) ERROR: No .egg-info directory found in /dev/shm/xplor-nih-root-8733/pip-pip-egg-info-36yqnfog PyInterp::command: error executing: >import runpy, sys runpy.run_module("pip", run_name="__main__") Pip works with my normal python distribution just fine, however I currently need to use this python version and so I would like to port my normal python environment into there. I don't expect official support for anything related to custom forks, but I would really appreciate any hints to fix the issue, because my knowledge of python and its environment is rather limited and I cannot extract any meaning out of this particular error message.
The text was updated successfully, but these errors were encountered:
Now seeing the same, cannot install llfuse
@callegar I believe the issue is with the llfuse setup.py which fails to build the metadata but exits with a success code. Running pip with -v may reveal the underlying error.
If no one has objections I'll let the bot close this one, as there is nothing we can do for this in pip.
@sbidoul I have investigated a bit the matter with llfuse . In my case, the issue was due to some missing header file from libfuse, hence certainly not a problem with pip . However, the message ERROR: No .egg-info directory found in /tmp/pip-pip-egg-info-kk0pn_g1 can happen to be extremely misleading for situations like this one because it appears to point an issue with the packaging of the python package that one is trying to install, rather than with the user environment. Incidentally, with older pip one gets a different, but equally misleading message ERROR: Files/directories not found in /tmp/pip-install-wyxx_tqb/llfuse/pip-egg-info .
I wonder whether the situation can be improved. It is unclear to me to what extent pip can recognize situations like mine (a missing header file) as of today to provide a better output. However, there should be a way for the inner package code taking care of the setup (I guess this is the package setup.py run with argument egg_info ) to report back when something goes wrong.
IMHO, the ERROR: Files/directories not found in /tmp/pip-install-wyxx_tqb/llfuse/pip-egg-info error message should at least be complemented by a "try re-running pip in verbose mode (-v) for detailed information" or something like that.
However, this would still be suboptimal in that -v produces way too much info. In my case, running with -v first produces the actual output of setup.py egg_info that is
Package fuse was not found in the pkg-config search path. Perhaps you should add the directory containing `fuse.pc' to the PKG_CONFIG_PATH environment variable No package 'fuse' found then you get the ERROR: Files/directories not found in /tmp/pip-install-wyxx_tqb/llfuse/pip-egg-info error message and finally you get a hundred lines of exception information that is hardly relevant to casual users. The best would be if pip had a way to print only the actual error output of the package, namely the Package fuse was not found. bit. Is there something that is less than -v but still enabling this output?