<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 dir="auto">And if one needs to classify packages type, why not add a new high level trove classifier ?</div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Le 23 févr. 2017 19:19, "Steve Dower" <<a href="mailto:steve.dower@python.org" target="_blank">steve.dower@python.org</a>> a écrit :<br type="attribution"><blockquote class="m_6142744227556990420quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_6142744227556990420quoted-text">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 class="m_6142744227556990420quoted-text">
On Feb 23, 2017, at 11:04 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a><br></div><div class="m_6142744227556990420elided-text">
<mailto:<a href="mailto: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 class="m_6142744227556990420elided-text">
<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 class="m_6142744227556990420elided-text"><br>
______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a href="mailto: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>