[Distutils] Maintaining a curated set of Python packages

[Wes Turner]

On Thursday, December 15, 2016, Wes Turner <wes.turner at gmail.com> wrote:

>
>
> On Thursday, December 15, 2016, Nick Coghlan <ncoghlan at gmail.com
> <javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>> wrote:
>
>> On 16 December 2016 at 00:39, Donald Stufft <donald at stufft.io> wrote:
>> > Theoretically we could allow people to not just select packages, but
>> also
>> > package specifiers for their “curated package set”, so instead of saying
>> > “requests”, you could say “requests~=2.12” or “requests==2.12.2”. If we
>> > really wanted to get slick we could even provide a requirements.txt file
>> > format, and have people able to install the entire set by doing
>> something
>> > like:
>> >
>> >     $ pip install -r
>> > https://pypi.org/sets/dstufft/my-cool-set/requirements.txt
>>
>> CurseGaming provide addon managers for a variety of game addons
>> (Warcraft, Minecraft, etc), and the ability to define "AddOn Packs" is
>> one of the ways they make it useful to have an account on the site
>> even if you don't publish any addons of your own. Even if you don't
>> make them public, you can still use them to sync your addon sets
>> between different machines.
>>
>> In the context of Python, where I can see this kind of thing being
>> potentially useful is for folks to manage package sets that aren't
>> necessarily coupled to any specific project, but match the way they
>> *personally* work.
>>
>> - "These are the packages I like to have installed to --user"
>> - "These are the packages I use to start a CLI app"
>> - "These are the packages I use to start a web app"
>> - etc...
>
>
> Does a requirements.txt in a {git,} repo solve for this already?
>

Could you just generate a README.rst for a long_description from
requirements.txt (or requirements.in, or pipfile),
store that in a {git,} repository,
and use the existing pypi release versioning and upload machinery?

Or would it be more useful to surface the other graph edges on project
pages?


- These additional queries would be less burdensome as AJAX requests to
JSON REST API views. Project pages could continue to load without waiting
for these additional cached edge bundles (and interactionStatistic(s)) to
load:
  - "This SoftwarePackage is in the following n SoftwarePackageCollections,
with the following comments and reviews"
  - "This SoftwarePackage has received n UserLikes (through Warehouse)"



> A Collection contains (hasPart) CreativeWorks
>
> - https://schema.org/Collection
> - https://schema.org/hasPart
>
> RDFa and JSONLD representations do parse as ordered lists.
>
> SoftwarePackageCollection
> SoftwareApplicationCollection
>
>
>> It also provides a way for people to vote on projects that's a little
>> more meaningful than stars - projects that appear in a lot of personal
>> stack definitions are likely to be generally valuable (the closest
>> equivalent to that today is mining code repositories like GitHub for
>> requirements.txt files and seeing what people are using that way).
>
>
> https://schema.org/InteractionCounter > https://schema.org/UserLikes
>
> D: CreativeWork
> - https://schema.org/interactionCount is now
> - https://schema.org/interactionStatistic
>
> (These are write-heavy features: they would change the database load of
> Warehouse)
>
>
>>
>> So yeah, if folks interested in this were to add it to Warehouse (and
>> hence pypi.org), I think it would definitely be a valuable enhancement
>> to the overall ecosystem. "What needs to be implemented in order to be
>> able to shut down the legacy service at pypi.python.org?" is the
>> *PSF's* focus, but that doesn't mean it needs to be everyone's focus.
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20161215/3fcc2342/attachment.html>