[Distutils] distlib and wheel metadata

[Daniel Holth]

I also get a little frustrated with this kind of proposal "no pins" which I
read as "annoy the publisher to try to prevent them from annoying the
consumer". As a free software publisher I feel entitled to annoy the
consumer, an activity I will indulge in inversely proportional to my desire
for users. Who is the star?

It should be possible to publish applications to pypi. Much of the
packaging we have is completely web application focused, these applications
are not usually published at all.

On Wed, Feb 15, 2017 at 12:58 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
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170215/3ddc604a/attachment.html>