Workflow of creating an ebuild

  1. PyPi is queried for an package with coresponding version (if no version is given, highest available is used)
  2. PyPi metadata is collected, and gpypi.enamer.Enamer.get_vars() is used to collect common ebuild variables
  3. Initial ebuild is written to overlay with SRC_URI
  4. Ebuild in unpacked with Portage API through shell
  5. Unpacked dir is inspected for information
  6. Ebuild is rendered again and written to an overlay
  7. Possible dependencies from are resolved and whole process is repeated for each one.

How are PV, PN, MY_PV, MY_PN and SRC_URI determined?

All the work is done by gpypi.enamer.Enamer.get_vars(). Specifically:

Tests against live PyPi – gpypi.tests.test_pypi

This module runs numerous tests against whole PyPI. It should be run manually, to detect new possible issues. All failures MUST be first written as unittests and then fixed accordingly.


Issues should not be closed until there are appropriate tests and documentation for the changeset.


List of features that may be implemented in no particular order:

  • atomic actions (cleanup on traceback/error)
  • migrate to simpleindex and xmlrpc API provided by distutils2
  • issue HEAD request to homepages (warn on failure)
  • finish SrcUriNamer implementation
  • implement setuptools Feature class
  • SVN/GIT/HG support as SRC_URI
  • implement homepage/src_uri as list (also includes config work)
  • decide what to do with configuartion on dependency ebuilds
  • search command
  • use rewriting system instead of regex for pn/pv parsing

Table Of Contents

Previous topic

User Guide

Next topic

Python API

This Page