[Pulp-list] [pulp_python] Roadmap and wishlist for future versions of the Pulp Python plugin

[Michael Hrivnak]

Looks good! I added a few questions below.

On Wed, Oct 25, 2017 at 12:47 PM, Daniel Alley <dalley at redhat.com> wrote:

> Pulp Python 3.0 Use Cases
>
>
> *[3.0] Synced Package Index Use Case:*As a user, I can configure an
> importer to sync a list of projects
>
>    - Syncing a project includes all releases
>    - Syncing a release includes all distribution packages (all types)
>
> As a user, I can publish a repository:
>
>    - Published Distributions are consumable by pip
>
>
minor suggestion: call this Distributed Publications. A publication comes
first, and then it gets distributed.


>
>    - Published projects are consumable by other Pulps
>    - Published projects will include all releases and distributions
>
> *Upload Use Case:*
>
> *[3.0] *As a user, I can upload individual distribution packages (name,
> version, platform)
>
>    - As a user I can upload an egg
>    - As a user I can upload a wheel
>    - As a user I can upload a sdist
>
> *[3.1+]* A twine user can publish a distribution package to Pulp
>
I'm interested to know more about how this would work. Would it require
implementing a type-specific API for creating/uploading content?


>
>
> *[3.1+] Granular Sync Use Case:*
> Blacklist: As a user, I can disinclude some content of a project
>
>    - By specifying (release, distribution package)
>    - 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
>
>    - From the output of pip freeze (loose use case)
>    - With the name, exact versions, and distribution type (tight use case)
>
>
How would you prioritize the whitelist vs. blacklist features?

It seems like "As a user, I can configure an importer to sync a list of
projects" is already a whitelist approach, but less specific. It may be
worth planning the UX for all of the whitelist features up-front so you can
find opportunities to accomplish them with similar or the same mechanisms.
For example, it might be overkill to offer the user the chance to specify
project names comma-separated, or the output of pip freeze, or
name/version/type as CSV/JSON/similar. Maybe there's a way to consolidate
some of that?



> *[3.1+] PyPI Publish Use Case:*
>
> As a user, I can publish a release to a remote package index
>
>    - As a user, I can configure Pulp to publish to PyPI with my auth
>    credentials
>
> Are the above two different use cases? They look real similar, and I'm not
sure why one is a bullet under the other.


>
> *[3.1+]* PyPI *Cache Use Case:*
>
> As a user, I can use Pulp as a PyPI cache
>

Does this just mean taking advantage of the on-demand features of Pulp? Or
is there anything more to it? If it's just the former, you'll probably get
this for free from core.

-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20171025/a3ab4958/attachment.htm>