[Distutils] distlib and wheel metadata

[Freddy Rietdijk]

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

> Thanks for your reply, it was very helpful.
>
> On 15 February 2017 at 16:55, Freddy Rietdijk <freddyrietdijk at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170216/12fa9ac7/attachment.html>