<div dir="ltr"><span style="font-size:12.8px">> Sort of repeating my earlier question, but how often does this happen</span><br style="font-size:12.8px"><span style="font-size:12.8px">in reality?</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">From a quick check in our repo we have patched about 1% of our packages to remove the constraints. We have close to 2000 Python packages. We don't necessarily patch all the constraints, only when they collide with the version we would like the package to use so the actual percentage is likely higher.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Larger applications that have many dependencies that are fixed have been kept out of Nixpkgs for now. Their fixed dependencies means we likely need multiple versions of packages. While Nix can handle that, it means more maintenance. We have a tool that can take e.g. a requirements.txt file and generate expressions, but it won't help you much with bug-fix releases when maintainers don't update their pinned requirements.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">And how </span><span style="font-size:12.8px">often is it that a simple request/PR to the package author to remove</span></div><span style="font-size:12.8px">the explicit version requirements is rejected?</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That's hard to say. If I look at what packages I've contributed to Nixpkgs, then in my experience this is something that is typically dealt with by upstream when asked.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> If you *do* get in a situation where the package explicitly requires</span><br style="font-size:12.8px"><span style="font-size:12.8px">certain versions of its dependencies, and you ignore those</span><br style="font-size:12.8px"><span style="font-size:12.8px">requirements, then presumably you're taking responsibility for</span><br style="font-size:12.8px"><span style="font-size:12.8px">supporting a combination that the upstream author doesn't support. How</span><br style="font-size:12.8px"><span style="font-size:12.8px">do you handle that?</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Typical situations are bug-fix releases. So far I haven't encountered any issues with using other versions, but like I said, larger applications that pin their dependencies have been mostly kept out of Nixpkgs. If we do encounter issues, then we have to find a solution. The likeliest situation is that an application requires a different version, an in that case we would then have an expression/package of that version specifically for that application. We don't have a global site-packages so we can do that.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Nick said he wants to guide authors away from explicit version</span></div><span style="font-size:12.8px">pinning. That's fine, but is the problem so big that the occasional</span><br style="font-size:12.8px"><span style="font-size:12.8px">bug report to offending projects saying "please don't pin exact</span><br style="font-size:12.8px"><span style="font-size:12.8px">versions" is insufficient guidance?</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The main problem I see is that it limits in how far you can automatically update to newer versions and thus release bug/security fixes. Just one inappropriate pin is sufficient to break dependency solving.</span><br><div><span style="font-size:12.8px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 5:14 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15 February 2017 at 15:50, Freddy Rietdijk <<a href="mailto:freddyrietdijk@fridh.nl">freddyrietdijk@fridh.nl</a>> wrote:<br>
> It's quite frustrating as a downstream having to deal with packages where<br>
> versions are pinned unnecessarily and therefore I've also requested on the<br>
> Setuptools tracker a flag that ignores constraints [1] (though I fear I<br>
> would have to pull up my sleeves for this one :) ) .<br>
<br>
</span>Sort of repeating my earlier question, but how often does this happen<br>
in reality? (As a proportion of the packages you deal with). And how<br>
often is it that a simple request/PR to the package author to remove<br>
the explicit version requirements is rejected? (I assume your first<br>
response is to file an issue with upstream?)<br>
<br>
If you *do* get in a situation where the package explicitly requires<br>
certain versions of its dependencies, and you ignore those<br>
requirements, then presumably you're taking responsibility for<br>
supporting a combination that the upstream author doesn't support. How<br>
do you handle that?<br>
<br>
I'm not trying to pick on your process here, or claim that<br>
distributions are somehow doing things wrongly. But I am trying to<br>
understand what redistributors' expectations are of package authors.<br>
Nick said he wants to guide authors away from explicit version<br>
pinning. That's fine, but is the problem so big that the occasional<br>
bug report to offending projects saying "please don't pin exact<br>
versions" is insufficient guidance?<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span></blockquote></div><br></div>