Jump to: navigation, search


Revision as of 08:40, 7 November 2013 by Lyz (talk | contribs)

Adding a Requirement to an OpenStack Project

In order to add or change a Python dependency requirement of an OpenStack project, it must first be added to the openstack/requirements repository.

Add it to the 'test-requires' or 'pip-requires' files as appropriate and submit it for review.

The requirement specification should usually include both a lower and upper bound. The lower bound should reflect the oldest known version of the package which has the APIs required. An upper bound should be added based on a package's policy of release versioning with respect to incompatible API changes so that we avoid problems caused a future incompatible release.

Once the change to openstack/requirements has merged, the local pypi mirror will be updated and then the requirements file for the OpenStack project may be updated. The new requirement specification must match exactly what is in openstack/requirements.

Requirements Team

Changes to openstack/requirements are approved by the requirements-core team in Gerrit. If you have an interest in coordinating dependency package versions across all the OpenStack projects and vetting new dependencies for their suitability for inclusion, please start reviewing changes to openstack/requirements. As your gain experience and your reviews are found helpful, you may be asked to join the core team.

Review Criteria

Consider the following criteria when reviewing changes to openstack/requirements

  • license (Apache2, MIT, BSD are probably okay, Copyleft licenses may be okay depending on circumstances)
  • python3 compatibility (all new requirements should be python3 compatible)
  • active development
  • prefer items already packaged in distros
  • project has api compat commitment/policy
  • apply the same considerations to transitive dependencies
  • commit log message includes reasoning for update
  • commit log message includes information about the OpenStack project(s) using the requirement

Additionally, regarding upstream version

  • minor upstream version updates should be considered routine/cursory review
  • use of pre-release versions of things needs an explanation
  • requirements with a missing upper bound on < next major number are dangerous