<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 23, 2017 at 1:56 PM, Xavier Fernandez <span dir="ltr"><<a href="mailto:xav.fernandez@gmail.com" target="_blank">xav.fernandez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></blockquote></div><div class="gmail_extra"><br></div>FWIW, an application packaging tool a wrote several years ago used to hit into dependency solver problems quite often. The tool leaned on distlib (which is a pretty nice library, but strict, as noted in OP) because there is/was no interface to pip. IIRC we upstreamed a few patches related to this and for sure carried some local patches.<div><br></div><div>The distlib solver would bind up from impossible constraints, yet every time, pip found a way to "power through" the exact same configuration despite blatantly incompatible metadata at times. I never looked into it further on pip's side (though probably someone here can confirm/deny this) but I suspect poor metadata is more widespread than pip makes visible.</div><div><br></div><div>I had a dump from 2014 of the distlib data at <a href="http://red-dove.com">red-dove.com</a> and I ran a quick script against it:</div><div><br></div><div><a href="https://gist.github.com/anthonyrisinger/f9140191009fb1ec1434cb0585a4a75c">https://gist.github.com/anthonyrisinger/f9140191009fb1ec1434cb0585a4a75c</a></div><div><br></div><div><div>total_projects:    41228</div><div>total_projects_eq: 182</div><div>% affected:        0.44%</div><div>total_files:       285248</div><div>total_files_eq:    1276</div><div>% affected:        0.45%</div><div>total_reqs:        642447</div><div>total_reqs_bare:   460080</div><div>% affected:        71.61%</div></div><div><br></div><div>I know the distlib data (from 2014 at least) is imperfect, but this would suggest not many projects use "==" explicitly. Maybe the bigger problem is that 75% of requirements have no version specifier at all. I know for us this specifically contributed to our solver problems because distlib was eager about choosing a version for such requirements, even though a later package might fulfill the requirement. Maybe this has since changed, but we needed to patch it at the time [1].</div><div><br></div><div>We really have to figure out this distribution stuff friends. Existing files, new metadata files, old PEPs, new PEPs... it's looking a bit "broken windows theory" for the principal method used to share Python with the world, and the outsized lens though which Python is perceived. Maybe this means hard or opinionated decisions, but I really can't stress enough how much of a drag it is to an otherwise reasonably solid Python experience. There is a real perception that it's more trouble than it's worth, especially with many other good options at the table.</div><div><br></div><div>[1] <a href="https://github.com/anthonyrisinger/zippy/commit/1c5d34d89805c47188a18cfbe17cfc39a9cb4480#diff-a533aaf4eec84e7c5d85d2129e10514fR1168">https://github.com/anthonyrisinger/zippy/commit/1c5d34d89805c47188a18cfbe17cfc39a9cb4480#diff-a533aaf4eec84e7c5d85d2129e10514fR1168</a></div><div><br></div>-- <br><div class="gmail-m_-1851669038819412254gmail_signature"><br>C Anthony</div>
</div></div>