Pulp Python Roadmap » History » Revision 2
Revision 1 (dalley, 10/18/2017 09:46 PM) → Revision 2/27 (dalley, 10/25/2017 06:13 PM)
# Pulp Python Roadmap ## Pulp Python Use Cases ### 3.0 Synced Package Index use case: pulp_python can interact with any remote package index that supports the PyPI API: - As a user, I can sync individual distribution packages (name, version, platform) > - As a user, user I can configure sync an importer to egg from a remote package index > - As a user I can sync an wheel from a list of projects remote package index > >> Syncing - As a project includes all releases >> Syncing user I can sync an sdist from a remote package index - As a user, I can sync a release includes and all distribution its distributions packages (all types) > > (name, version) - As a user, I can publish a repository: > >> Published Distributions are consumable by pip >> Published projects are consumable by other Pulps >> Published projects will include sync all releases and distributions in a project (name) - As a user, I can blacklist distributions ### Upload Use Case: > 3.0 - from a repository > - globally - As a user, I can upload individual distribution packages filter the distributions synced based on version (name, version, platform) > >> version qualifier) - As a user user, I can upload an egg >> reproduce my environment by syncing packages from the output of pip freeze (name, and exact versions) - As a user user, I can upload publish a wheel >> distribution package to a remote package index - As a user user, I can configure Pulp to publish to PyPI with my auth credentials ### pulp_python can act as a package index that supports the PyPI API - I can upload a sdist > > 3.1+ distribution package to Pulp (standard Pulp upload API) - A twine user can publish a distribution package to Pulp - As a pip user I can install a package from a Pulp publication - As a user, Pulp can cache PyPI packages ### 3.1+ Granular Sync > Blacklist: ## Prioritized Use Cases - As a user, I can disinclude some content of sync all distributions in a project > >> By specifying (release, (name) - As a pip user I can install a package from a Pulp publication - I can upload a distribution package) >> package to Pulp (standard Pulp upload API - As a user, Pulp can cache PyPI packages - As a user, I am in control of which packages are in my repositories: > - As a user, I can disinclude content by distribution type filter the distributions synced based on version (name, version qualifier) > - As a user, I can sync a release and all its distributions packages (name, version) > Whitelist (Curated Package index Use Case) - As a user, I can sync individual distribution packages that reproduce a specific environment (name, version, platform) > >> From - As a user I can sync an egg from a remote package index >> - As a user I can sync an wheel from a remote package index >> - As a user I can sync an sdist from a remote package index - As a user, I can reproduce my environment by syncing packages from the output of pip freeze (loose use case) >> With the name, (name, and exact versions, and distribution type (tight use case) ### 3.1+ PyPI Publish use case > versions) - As a user, I can publish a release distribution package to a remote package index PyPI > >> - As a user, I can configure Pulp to publish to PyPI with my auth credentials ### 3.1+ Cache Use Case: > - A twine user can publish a distribution package to Pulp - As a user, I can use Pulp as blacklist distributions > - from a PyPI cache. repository > - globally ## 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 repo) ### 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)
.