Pulp

# Pulp Python Roadmap

Legend:  

(Red, undecided)  

(Yellow, decided- needs story)  

(blue, decided with story)  

(Black - Finished bc green is hard to read)

~~~

This is a living document that is moving towards a long term plan to develop pulp_python 3.0 and beyond.

~~~

## Pulp Python 3.0 Use Cases

### Synced Package Index use case:

As a user, I can configure an importer to sync a list of projects \[#2884\]

  - Syncing a project includes all releases

  - Syncing a release includes all distribution packages (all types)

  - <span style="color:blue;">Synced packages can be verified based on digest (md5 from pypi, sha512 Pulp)</span> \[#3613\]

  - I can specify sync mode to be either additive or mirror

  - {color:blue} I can sync all projects from a package index \[#985\]

  - {color:blue} I can sync the metadata of projects and defer the download of packages (lazy sync) \[#1884\]

  - Blacklist: As a user, I can disinclude some content of a project by version specifiers and digests

  - Whitelist (Curated Package index Use Case) As a user, I can sync packages that reproduce a specific environment by version specifiers and digests

### Publish Use Case:

As a user, I can publish a repository (Published projects will include all releases and distributions)

  - Published Python Content Units are consumable by pip \[#2885\]

  - {color:blue} Published Python Content Units are consumable by pipenv \[#4686\]

  - {color:blue} I can published projects are consumable by other Pulp instances \[#2886\]

### Upload Use Case:

As a user, I can upload individual distribution packages (name, version, platform) \[#3197\]

  - As a user I can upload all types (egg, wheel, sdist)

  - {color:blue} As a user, I can upload and create a PythonPackageContent in a single call (one-shot upload)

### As a user I have documentation that covers all above in this format:

  - Quickstart 

      - Installation

      - upload \[#3212\]

      - sync \[#3213\]

      - {color:blue} publish \[#3214\]

  - REST API Reference

  - Build and host docs \[#3215\]

## Pulp Python 3.1+ Use Cases

### Upload Use Case:

> A twine user can publish a distribution package to Pulp \[#2887\]

### Migrations:

> As a user, I can migrate Pulp2 packages to Pulp3 in-place. \[#2888\]

### Cache Use Case:

> As a user, I can use Pulp as a PyPI cache.

### Granular Sync

> Blacklist: As a user, I can disinclude some content of a project

~~\>\> By specifying (release, distribution package)~~ (Included in 3.0)

>> I can disinclude content by distribution type

~~\> Whitelist (Curated Package index Use Case) As a user, I can sync packages that reproduce a specific environment~~ (Included in 3.0)

>> From the output of pip freeze (loose use case)  

>> With the name, exact versions, and distribution type (tight use case)

## Glossary:

### Project

> A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a Distribution.  

> \[ https://packaging.python.org/glossary/#term-project \]

### Package Index:

> A repository of distributions with a web interface to automate package discovery and consumption. (this should align to a pulp repo). A Package Index is assumed to implement the PyPI APIs

### Release

> A snapshot of a Project at a particular point in time, denoted by a version identifier.  

> Making a release may entail the publishing of multiple Distributions. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format.

### Distribution Package

> "Distribution" for short. If we mean linux, we will say "distro"  

> A versioned archive file that contains Python packages, modules, and other resource files that are used to distribute a Release. The archive file is what an end-user will download from the internet and install. A project may contain many releases, and releases may contain many distribution packages. Can be type sdist, bdist, etc. "Distribution package" is used instead of "package" to avoid confusion with "import packages" or linux "distributions".

## Relevant PEPs:

  - https://www.python.org/dev/peps/pep-0241/ Final (Original Metadata)

  - https://www.python.org/dev/peps/pep-0301/ Final (HTTP API)

  - https://www.python.org/dev/peps/pep-0314/ Final (Metadata 1.1)

  - https://www.python.org/dev/peps/pep-0345/ Accepted (Metadata 1.2)

  - https://www.python.org/dev/peps/pep-0427/ Accepted (Wheel 1.0) 

  - https://www.python.org/dev/peps/pep-0491/ Draft (Wheel 1.9)

  - https://www.python.org/dev/peps/pep-0426/ Deferred (Metadata 2.0)

  - https://www.python.org/dev/peps/pep-0459/ Deferred (Standard Metadata Extensions)

  - https://www.python.org/dev/peps/pep-0503/ Accepted (Simple API)

  - https://www.python.org/dev/peps/pep-0508/ Active (Dep specification)