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

Austin Macdonald amacdona at redhat.com
Fri Dec 8 13:43:38 UTC 2017


On Wed, Oct 25, 2017 at 2:44 PM, Michael Hrivnak <mhrivnak at redhat.com>
wrote:

> 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.
>

In this case, we are using the python definition, which is a "Distribution
Package". In Pulp terms, this is a Python Content Unit. We are still
adjusting our language to help with overloading. This line just means that
content that has been published is consumable by pip.

>
>
>>
>>    - 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?
>

We are investigating this, but it would probably involve implementing a
live API endpoint.

>
>
>>
>>
>> *[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?
>

This is a "backburner" planning for 3.1+, but these are great points to
consider.

>
>
>
>> *[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.
>

This is just general -> specific. We are thinking this way so we can keep
warehouse in mind.


>
>
>>
>> *[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.
>

Just using on-demand. Hopefully, we won't have to do anything, but we
wanted to write it down anyway.


>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20171208/6f27fcb4/attachment.htm>


More information about the Pulp-list mailing list