> I notice here (and in a few other places) you talk about
"Applications". From what I understand of Nick's position,
applications absolutely should pin their dependencies - so if I'm
understanding correctly, those applications will (and should) continue
to pin exact versions.

Application developers typically don't test against all combinations of dependency versions and it also doesn't really make sense for them. Therefore it is understandable from their point of view to pin their dependencies. However, should they pin to a certain major/minor version, or to a patch version? In my opinion they best pin to minor versions. That should be sufficient to guarantee the app works. Let the distributions take care of providing the latest patch version so that it remains safe. And that means indeed specifying >1.6,<1.8 (or actually >=1.7,<1.8), and not ==1.7 or ==1.7.3. The same goes for the meta-packages.

On Wed, Feb 15, 2017 at 6:57 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Thanks for your reply, it was very helpful.

On 15 February 2017 at 16:55, Freddy Rietdijk <freddyrietdijk@fridh.nl> wrote:
> Larger applications that have many dependencies that are fixed have been
> kept out of Nixpkgs for now.

I notice here (and in a few other places) you talk about
"Applications". From what I understand of Nick's position,
applications absolutely should pin their dependencies - so if I'm
understanding correctly, those applications will (and should) continue
to pin exact versions.

As regards automatic packaging of new upstream versions (of libraries
rather than applications), I guess if you get upstream to remove the
pinned versions, this problem goes away.

> 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.

I'm not sure I follow this. Suppose we have foo 1.0 depending on bar.
If foo 1.0 has doesn't pin bar (possibly because you reported to them
that they shouldn't) then foo 1.1 isn't going to suddenly add the pin
back. So you can update foo fine. And you can update bar because
there's no pin. So yes, while "one inappropriate pin" can cause a
problem, getting upstream to fix that is a one-off cost, not an
ongoing issue.

So, in summary,

* I agree that libraries pinning dependencies too tightly is bad.
* Distributions can easily enough report such pins upstream when the
library is initially packaged, so there's no ongoing cost here (just
possibly a delay before the library can be packaged).
* Libraries can legitimately have appropriate pins (typically to
ranges of versions). So distributions have to be able to deal with
that.
* Applications *should* pin precise versions. Distributions have to
decide whether to respect those pins or remove them and then take on
support of the combination that upstream doesn't support.
* But application pins should be in a requirements.txt file, so
ignoring version specs is pretty simple (just a script to run against
the requirements file).
* Because Python doesn't support multiple installed versions of
packages, conflicting requirements *will* be a problem that distros
have to solve themselves (the language response is "use a venv").

Nick is suggesting that the requirement metadata be prohibited from
using exact pins, but there's alternative metadata for "yes, I really
mean an exact pin". To me:

1. This doesn't have any bearing on *application* pins, as they aren't
in metadata.
2. Distributions still have to be able to deal with libraries having
exact pins, as it's an explicitly supported possibility.
3. You can still manage (effectively) exact pins without being
explicit - foo >1.6,<1.8 pretty much does it. And that doesn't even
have to be a deliberate attempt to break the system, it could be a
genuine attempt to avoid known issues, that just got too aggressive.

So we're left with additional complexity for library authors to
understand, for what seems like no benefit in practice to distribution
builders. The only stated benefit of the 2 types of metadata is to
educate library authors of the benefits of not pinning versions - and
it seems like a very sweeping measure, where bug reports from
distributions seem like they would be a much more focused and just as
effective approach.

Paul