<br><br>On Thursday, December 15, 2016, Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Thursday, December 15, 2016, Nick Coghlan <<a href="javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');" target="_blank">ncoghlan@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16 December 2016 at 00:39, Donald Stufft <<a>donald@stufft.io</a>> wrote:<br>
> Theoretically we could allow people to not just select packages, but also<br>
> package specifiers for their “curated package set”, so instead of saying<br>
> “requests”, you could say “requests~=2.12” or “requests==2.12.2”. If we<br>
> really wanted to get slick we could even provide a requirements.txt file<br>
> format, and have people able to install the entire set by doing something<br>
> like:<br>
><br>
>     $ pip install -r<br>
> <a href="https://pypi.org/sets/dstufft/my-cool-set/requirements.txt" target="_blank">https://pypi.org/sets/dstufft/<wbr>my-cool-set/requirements.txt</a><br>
<br>
CurseGaming provide addon managers for a variety of game addons<br>
(Warcraft, Minecraft, etc), and the ability to define "AddOn Packs" is<br>
one of the ways they make it useful to have an account on the site<br>
even if you don't publish any addons of your own. Even if you don't<br>
make them public, you can still use them to sync your addon sets<br>
between different machines.<br>
<br>
In the context of Python, where I can see this kind of thing being<br>
potentially useful is for folks to manage package sets that aren't<br>
necessarily coupled to any specific project, but match the way they<br>
*personally* work.<br>
<br>
- "These are the packages I like to have installed to --user"<br>
- "These are the packages I use to start a CLI app"<br>
- "These are the packages I use to start a web app"<br>
- etc...</blockquote><div><br></div><div>Does a requirements.txt in a {git,} repo solve for this already?</div></blockquote><div><br></div><div>Could you just generate a README.rst for a long_description from requirements.txt (or <a href="http://requirements.in">requirements.in</a>, or pipfile),</div><div>store that in a {git,} repository, </div><div>and use the existing pypi release versioning and upload machinery?</div><div><br></div><div>Or would it be more useful to surface the other graph edges on project pages? </div><div><br></div><div><br></div><div>- 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:</div><div>  - "This SoftwarePackage is in the following n SoftwarePackageCollections, with the following comments and reviews"</div><div>  - "This SoftwarePackage has received n UserLikes (through Warehouse)"</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>A Collection contains (hasPart) CreativeWorks</div><div><br></div><div>- <a href="https://schema.org/Collection" target="_blank">https://schema.org/Collection</a></div><div>- <a href="https://schema.org/hasPart" target="_blank">https://schema.org/hasPart</a></div><div><br></div><div>RDFa and JSONLD representations do parse as ordered lists.</div><div><br></div><div>SoftwarePackageCollection</div><div>SoftwareApplicationCollection</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It also provides a way for people to vote on projects that's a little<br>
more meaningful than stars - projects that appear in a lot of personal<br>
stack definitions are likely to be generally valuable (the closest<br>
equivalent to that today is mining code repositories like GitHub for<br>
requirements.txt files and seeing what people are using that way).</blockquote><div><br></div><div><a href="https://schema.org/InteractionCounter" target="_blank">https://schema.org/<wbr>InteractionCounter</a> > <a href="https://schema.org/UserLikes" target="_blank">https://schema.org/UserLikes</a></div><div><br></div><div>D: CreativeWork</div><div>- <a href="https://schema.org/interactionCount" target="_blank">https://schema.org/<wbr>interactionCount</a> is now</div><div>- <a href="https://schema.org/interactionStatistic" target="_blank">https://schema.org/<wbr>interactionStatistic</a></div><div><br></div><div>(These are write-heavy features: they would change the database load of Warehouse)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So yeah, if folks interested in this were to add it to Warehouse (and<br>
hence <a href="http://pypi.org" target="_blank">pypi.org</a>), I think it would definitely be a valuable enhancement<br>
to the overall ecosystem. "What needs to be implemented in order to be<br>
able to shut down the legacy service at <a href="http://pypi.python.org" target="_blank">pypi.python.org</a>?" is the<br>
*PSF's* focus, but that doesn't mean it needs to be everyone's focus.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a>ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a>Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/distutils-sig</a><br>
</blockquote>
</blockquote>