> Sort of repeating my earlier question, but how often does this happen
in reality?

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.

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.

> And how often is it that a simple request/PR to the package author to remove
the explicit version requirements is rejected?

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.

> If you *do* get in a situation where the package explicitly requires
certain versions of its dependencies, and you ignore those
requirements, then presumably you're taking responsibility for
supporting a combination that the upstream author doesn't support. How
do you handle that?

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.

> Nick said he wants to guide authors away from explicit version
pinning. That's fine, but is the problem so big that the occasional
bug report to offending projects saying "please don't pin exact
versions" is insufficient guidance?

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.


On Wed, Feb 15, 2017 at 5:14 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 15 February 2017 at 15:50, Freddy Rietdijk <freddyrietdijk@fridh.nl> wrote:
> It's quite frustrating as a downstream having to deal with packages where
> versions are pinned unnecessarily and therefore I've also requested on the
> Setuptools tracker a flag that ignores constraints [1] (though I fear I
> would have to pull up my sleeves for this one :) ) .

Sort of repeating my earlier question, but how often does this happen
in reality? (As a proportion of the packages you deal with). And how
often is it that a simple request/PR to the package author to remove
the explicit version requirements is rejected? (I assume your first
response is to file an issue with upstream?)

If you *do* get in a situation where the package explicitly requires
certain versions of its dependencies, and you ignore those
requirements, then presumably you're taking responsibility for
supporting a combination that the upstream author doesn't support. How
do you handle that?

I'm not trying to pick on your process here, or claim that
distributions are somehow doing things wrongly. But I am trying to
understand what redistributors' expectations are of package authors.
Nick said he wants to guide authors away from explicit version
pinning. That's fine, but is the problem so big that the occasional
bug report to offending projects saying "please don't pin exact
versions" is insufficient guidance?

Paul