[Distutils] distlib and wheel metadata

[Freddy Rietdijk]

> 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 at gmail.com> wrote:

> On 15 February 2017 at 15:50, Freddy Rietdijk <freddyrietdijk at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170215/69c594dc/attachment.html>