hvr_

> Would it be possible to do this more like GNU configure does? The software specifies what it needs, and the system looks for a version that works. How about check the Haskell code automatically to see what functions it uses?

This gets often suggested every time the version bounds topic comes up (to some degree, that's the direction backpack is going btw). But unfortunately this does not work:

Because what this argument ignores is that you get a similar problem you have with duck-typing on a different level: You assume that the same name & type-signature provides the same semantics. However, the types usually leave too much degree of freedom to provide a proper contract. And you have to find a way to encode that contract.

The best-bang-for-buck way we currently have to encode this contract is... well... the PVP! Version numbers announce the contract, while version bounds define which contract you rely on.

Unless we have a better way to solve this, there's no alternative to the PVP. Unfortunately, so far I have not heard any workable solution from PVP complainers. So that's that.

> That said, I do not want trustees to fix my stuff.

As soon as you upload stuff to Hackage, it enters the work-queue for Hackage Trustees. That's because the Hackage Trustees' mission is to make sure that Hackage remains in a healthy state. Which, by the way, wouldn't be needed in the first place, if everyone played voluntarily by what you call "your preferred rules", i.e. the PVP. Luckily, in many cases it's just an oversight, and in thoses cases people are actually grateful for the heads-up.

Consequently, the only way to keep Hackage Trustees from messing with your stuff is to refrain from uploading to Hackage.

> I would fully support a way to get stuff into Stackage that skips Hackage. I think it would reduce a lot of this friction.

That's actually an intriguing idea and to be honest I am surprised that Stackage hasn't implemented something to this end already. After all, Stackage curators keep busy fighting against overly strict version bounds, while Hackage trustees are busy fighting against inaccurately lax version bounds... this is quite yin-and-yang-esque ;-)

> Using someone else's curation winds up being much less work for me than using a solver, so that's what I do.

:-(

So basically, you value your time more than the time of us Hackage Trustees, who now have to fix the mess you're leaving behind on Hackage. That's like justifying littering because that's less work, since there's public services anyway which pick up the garbage you leave behind.

If you have the time to write software, package it up, write tests, package it up, and upload to Hackage, then is it really asked too much to go that extra mile and follow the PVP to not waste our time?

> It just doesn't work well, and the maintainer / hackage trustee overhead is too damn high.

The trustee overhead is only too damn high if people start leaving off upper bounds more frequently. We're tweaking and adding features into `cabal-install` to encourage proper PVP bounds when uploading to Hackage.

On the other hand, Stack unfortunately undoes this by having harming defaults here.

So, to put this bluntly, by having bad defaults, Stack is actively contributing to overload Hackage Trustees.

> My theory is that the folks who are adamant about the PvP are either damn tenacious and dedicated (hvr, dcoutts, etc), or people who don't deal with projects with many dependencies and custom packages.

Well, that's a very bold theory...

> See, for instance, the following from someone with no connection to FP Complete that I'm aware of

You may be interested to know that Carter (the guy you're quoting) knows better today, and has even become a Hackage Trustee whose mission is more or less to uphold those very PVP upper bounds ;-)