This is a command line interface for Pulp 3.

This software is in beta and future releases may include backwards incompatible changes.

pulp [<global_options>] <plugin> <resource_class> [--type <resource_type>] <action> [<action_options>]

Global options include:

• --base-url
• --user
• --password
• --config
• --format
• -v/-vv/-vvv

To install and use the CLI, run these commands:

pip install pulp-cli[pygments]
pulp config create -e

Read the installation and configuration doc for more information.

• Redirecting from http to https, as done by a typical Pulp installation, does not work properly with POST and PUT requests. Please use https:// in the base url. Note that the attempt to use http leaks sensitive data over an unencrypted connection.

pulp status

pulp file repository list

pulp file repository create --name file_repo1

pulp file repository update --name file_repo1 --description "Contains plain files"

pulp file repository destroy --name file_repo1

The CLI uses the click package which supports shell completion. To configure this, check out click's documentation. As an example, here is what to add to your ~/.bashrc file if you're using bash:

eval "$(_PULP_COMPLETE=source_bash pulp)"

If you take the time to evaluate, test, or build your own CLI commands, please complete this survey, and we will gladly ship you some SWAG!

pulp-cli comes with python type annotations and black code formatting. To verify your code please run black, flake8, shellcheck, and mypy. Run make lint to check for compliance. Also please follow The seven rules of a great Git commit message.

In order to be able to access every (sub-)commands help page, it is necessary that no code outside of the final performing command callback accesses the api property of the PulpContext. There are some facilities that perform lazy loading to help with that requirement. Those include:

• PulpContext.api
• PulpContext.needs_version
• PulpEntityContext.entity
• PulpEntityContext.pulp_href

This cli for Pulp 3 will be versioned indedendently of any version of the server components. It is supposed to be able to communicate with different combinations of server component versions at the same time. So it might be needed to guard certain features / workarounds by the available server plugin version. As a rule of thumb, all necessary workarounds should be implemented in the corresponding Context objects to provide a consistent interface to the command callbacks.

Tests are shell scripts in tests/scripts with names like test_*.sh. They should should focus on the cli operation and are not a replacement for pulp integration tests; i.e. make sure the cli translates to the right api calls, but do not care about pulp internals.

In order to run tests, a running instance of pulp with all necessary plugins installed must be configured in tests/settings.toml.

To run tests:

make test                           # all tests
pytest -m pulp_file                 # tests for pulp_file
pytest -m pulp_file -k test_remote  # run tests/scripts/pulp_file/test_remote.sh

1. Generate the changelog (eg towncrier --yes --version 0.1.0) and commit
2. Run bumpversion release, commit your local changes, and note the commit sha
3. Run bumpversion minor to update the version to the next dev release version
4. Push your commits, open a PR, and get it merged
5. After your PR is merged, pull the latest changes from develop
6. Now tag your release commit (e.g. git tag 0.1.0) and push to pulp/pulp-cli
7. Monitor the build job and then check PyPI to make sure the package has been uploaded
8. Send an email to pulp-list and pulp-dev to announce the release