Last modified 4 years ago Last modified on 08/06/12 20:16:47


The following page describes the steps necessary to configure your local environment for Pulp development.

Source Code

The Pulp repositories are accessed through git at the following URLs based on the level of access required:


$ git clone git://


$ git clone

If you have been approved for git commit access to the Pulp git repository, the following steps are necessary:


The easiest way to download the dependencies is to install Pulp through yum, which will pull in the latest dependencies according to the spec file.

  1. Install the four primary pulp packages to get all of the dependencies.
    $ sudo yum install pulp-rpm-server pulp-rpm-admin-client pulp-rpm-consumer-client pulp-rpm-agent
  1. Remove the installed Pulp RPMs; these will be replaced with running directly from the checked out code.
    $ sudo yum remove pulp-admin-client pulp-agent pulp-builtins-admin-extensions pulp-builtins-consumer-extensions pulp-consumer-client pulp-rpm-admin-client pulp-rpm-admin-extensions pulp-rpm-agent pulp-rpm-consumer-client pulp-rpm-consumer-extensions pulp-rpm-handlers pulp-rpm-plugins pulp-rpm-server pulp-server python-pulp-agent-lib python-pulp-bindings python-pulp-client-lib python-pulp-common python-pulp-rpm-common

The only caveat to this approach is that these dependencies will need to be maintained after this initial setup. Leaving the testing builds repository enabled will cause them to be automatically updated on subsequent yum update calls. Messages are sent to the Pulp mailing list when these dependencies are updated as well to serve as a reminder to update before the next code update.


Pulp can be installed to run directly from the checked out code base through scripts. Running these scripts requires the python-setuptools package to be installed. Additionally, it is also recommended to install python-pip for access to additional setup-related features.

This method of installation links the git repositories as the locally deployed libraries and scripts. Any changes made in the working copy will be immediately deployed in the site-packages libraries and installed scripts. There are two such setup scripts that need to be run.

$ cd <pulp root>/platform/src
$ sudo python ./ develop
$ cd <pulp root>/rpm-support/src
$ sudo python ./ develop

Additionally, Pulp specific files such as configuration and package directories must be linked to the checked out code base. These additions are not performed by but rather by the Pulp specific script

$ cd <pulp root>
$ sudo python ./ -I


The script has an uninstall option that will remove the symlinks from the system into the local source directory.

$ cd <pulp root>
$ sudo ./ -U


The script links Pulp's WSGI application into the checked out code base. In many cases, Apache will not have the required permissions to serve the applications (for instance, if the code is checked out into a user's home directory).

For example:

$ ls -l /srv/pulp/
lrwxrwxrwx  1 root   root   50 Aug 11 20:05 webservices.wsgi -> /home/jdob/code/pulp/srv/pulp/webservices.wsgi

One solution, if your system supports it, is to use ACLs to grant Apache the required permissions.

For example, assuming the Pulp source was checked out to ~/code/pulp, the following series of commands would grant Apache the required access:

$ cd $HOME
$ setfacl -m user:apache:rwx .
$ cd code
$ setfacl -m user:apache:rwx .
$ cd pulp
$ setfacl -m user:apache:rwx .


If you are running with SELinux enabled you will need to follow the steps here: SELinux/DevSetup


Pulp is a mod_wsgi application. The mod_wsgi and mod_python modules can not both be loaded into apache at the same time as they conflict in odd ways. Either uninstall mod_python before starting Pulp or make sure the mod_python module is not loaded in the Apache config.

Initialize and Start

At this point, the Server Installation guide can be followed to initialize and start Pulp.

Keep in mind that code changes will often require Apache to be restarted to load the changes.

Unit Tests

See: Unit Tests

Tests are located in each of the subprojects (platform, builtins, rpm-support, etc). A script in the git root called will run tests across all of the subprojects and generate a single coverage report in the git root directory.

Unit Test Coverage

  1. Install the coverage plugin for nosetests:
    $ easy_install coverage
  1. When you run the test suite with nosetests, pass in the following flags:
    $ nosetests --with-coverage --cover-html --cover-package pulp --cover-erase

A quick explanation:

  • --with-coverage - actually does the coverage checking
  • --cover-html - generate HTML pages instead of just the console output
  • --cover-package pulp - says to only generate coverage numbers for the pulp project; if not you get a lot more fluff in the output
  • --cover-erase - erase the previously generated reports if they exist

That'll put them in a directory called "cover" which I think is in "unit" (it may be your cwd if you run with -w).