<br><br>On Thursday, February 23, 2017, Xavier Fernandez <<a href="mailto:xav.fernandez@gmail.com">xav.fernandez@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">+1 also.<div dir="auto">This whole double requirement feels over-complicated for what seems like a rather small usecase: it would be interesting to have a few stats on the number of packages concerned by this pinning (maybe just scan all the last uploaded wheels of each package ?).</div><div dir="auto"><br></div></div></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">And if one needs to classify packages type, why not add a new high level trove classifier ?</div></div></blockquote><div><br></div><div>+1 This could be accomplished with a trove classifier (because Entity Attribute boolean-Value)</div><div><br></div><div>The component/library, application, metapackage categorical would require far more docs than:</div><div><br></div><div> pip install --ignore-versions metapkgname</div><div><br></div><div>Which is effectively, probably, maybe the same? as:</div><div><br></div><div> pip install metapkg</div><div> pip install --upgrade __ALL__</div><div><br></div><div><br></div><div>... say, given that metapkgname requires (install_requires) ipython, and the requirements.txt is:</div><div><br></div><div> metapkgname # ipython==4.2</div><div> ipython</div><div><br></div><div>If pip freeze returns:</div><div><br></div><div> ipython</div><div> metapkgname</div><div><br></div><div>And I then:</div><div><br></div><div> pip freeze -- | xargs pip install --upgrade</div><div><br></div><div>Haven't I then upgraded ipython past the metapackage pinned version, anyway?</div><div><br></div><div><a href="http://stackoverflow.com/questions/2720014/upgrading-all-packages-with-pip">http://stackoverflow.com/questions/2720014/upgrading-all-packages-with-pip</a></div><div><br></div><div>The best workaround that I'm aware of:</div><div>- Create integration test and then build scripts</div><div>- Run test/build script in a container</div><div>- Change dependencies, Commit, Create a PR, (e.g. Travis CI runs the test/build/report/post script), Review integration test output</div><div><br></div><div>What integration tests do the RPM/DNF package maintainers run for, say, django, simplejson, [and psycopg2, for django-ca]? If others have already integration-tested even a partially overlapping set, that's great and it would be great to be able to store, share, and search those build artifacts (logs, pass/fail).</div><div><br></div><div><br></div><div>Additionally, practically, could we add metadata pointing to zero or more OS packages, per-distribution? How do I know that there's probably a somewhat-delayed repackaging named "python-ipython" which *might* work with the rest of the bleeding edge trunk builds I consider as stable as yesterday, given which tests?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Le 23 févr. 2017 19:19, "Steve Dower" <<a href="javascript:_e(%7B%7D,'cvml','steve.dower@python.org');" target="_blank">steve.dower@python.org</a>> a écrit :<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 23Feb2017 0914, Donald Stufft wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Feb 23, 2017, at 11:04 AM, Nick Coghlan <<a href="javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');" target="_blank">ncoghlan@gmail.com</a><br></div><div>
<mailto:<a href="javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');" target="_blank">ncoghlan@gmail.com</a>>> wrote:<br>
<br>
Redistributors may *ask* a publisher to reclassify their project as a<br>
library or a devtool (and hence also avoid pinning their dependencies<br>
in order to make integration easier), but publishers will always have<br>
the option of saying "No, we want to you to treat it as an<br>
application, and we won't help your end users if we know you're<br>
overriding our pinned dependencies and the issue can't be reproduced<br>
outside your custom configuration".<br>
</div></blockquote><div>
<br>
<br>
This whole discussion feels like trying to overcomplicate something<br>
that’s already not a simple to solve a problem that I don’t think is<br>
really that widespread. My estimation is that 99% of people who are<br>
currently using ``==`` will just immediately switch over to using<br>
whatever flag we provide that allows them to still do that. Adding a “do<br>
the thing I asked for” detritus to the project seems like a bad idea.<br>
<br>
It’s not really any different than if a project say, only released<br>
Wheels. While we want to encourage projects to release sdists (and to<br>
not ping versions) trying to enforce that isn’t worth the cost. Like<br>
most packaging issues, I think that it’s best solved by opening up<br>
issues on the offending project’s issue tracker.<br>
</div></blockquote>
<br>
+1. This has been my feeling the entire time I spent catching up on the thread just now.<br>
<br>
As soon as "user education" becomes a requirement, we may as well do the simplest and least restrictive metadata possible and use the education to help people understand the impact of their decisions.<br>
<br>
Cheers,<br>
Steve<div><br>
______________________________<wbr>_________________<br>
Distutils-SIG maillist - <a href="javascript:_e(%7B%7D,'cvml','Distutils-SIG@python.org');" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/distutils-sig</a><br>
</div></blockquote></div><br></div></div>
</blockquote>