5 ms·

No, it isn't. I don't use HN much, just taking a look at this conversation. I shouldn't even respond to this comment considering its tone. You should keep in

No, it isn't. I don't use HN much, just taking a look at this conversation. I shouldn't even respond to this comment considering its tone. You should keep in mind that this was in discussion of a new serialization library, not the PVP. I actually had to create this new account because I forgot my password and my old account (probably mgsloan) doesn't have an email address associated. > All I said was that FP complete is setting a bad example by actively refusing to follow established community guidelines (PvP). We do follow the important parts of the PvP. Personally, I consider the 3rd section of the PvP a failed experiment. It just doesn't work well, and the maintainer / hackage trustee overhead is too damn high. 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. So, yes, we are willing to dump tradition when the tradition is nonsense. I think that Haskellers ought to understand this very well - tradition should be questioned - particularly when it is a major pain point. When there is great value in doing so, we are questioning some traditions and doing our own thing. This attitude appears to be ruffling the feathers of the vocal minority.

HaskellMuppet 10y ago
What are the important parts of the PvP and why are they important?
mightybyte 10y ago
The whole PVP debate really boils down to one simple question. Do you believe that a properly functioning dependency solver is important for the community? If you answer yes, then I think it's pretty straightforward to get from there to the conclusion that version bounds are necessary. And by the contrapositive, if you are arguing against upper bounds, then you are actually arguing against the usefulness of a solver. If you answer no, then we should debate the merits of having a solver.
- massysett 10y ago
  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? If I'm using `text`, and all I use from that package is `pack`, `unpack`, and `cons`, I shouldn't have to specify bounds. The Cabal way of doing this--specifying version bounds--creates a big maintenance burden. And even then, it does not always work. So yes, I would question the merits of having a solver that checks some version numbers that developers manually put in. That said, I lack the know-how or resources to come up with anything new, so I'm stuck using curation or a solver. Using someone else's curation winds up being much less work for me than using a solver, so that's what I do.
  - hvr_ 10y ago
    > 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?
    - massysett 10y ago
      dcoutts said it would not be appropriate to change Hackage to require upper bounds on software. It would be quite simple to change Hackage so that any upload would require upper bounds restricted only to package versions that already exist. Why has no such change been made? If I were in your situation I would not be spending time on menial work when a simple program could prevent that work. If such a change were made I would happily stop uploading to Hackage altogether. That no such change has been made suggests there is insufficient support for your position. I have not wasted any trustee's time, as all my software works and I keep it working or mark it deprecated. That said, I do not want trustees to fix my stuff. I have no desire to waste anyone's time. The only reason I upload to Hackage is to get stuff into Stackage. I would fully support a way to get stuff into Stackage that skips Hackage. I think it would reduce a lot of this friction. However I can understand why Stackage has no such method: Hackage allows no upper bounds. This suggests that people value a large unfragmented Hackage more than they value required upper bounds. Of course I have no role in telling you how to spend your time, but if I were you I would stop fixing software that does not play by your preferred rules.
hvr_ 10y ago
> 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...

HaskellMuppet 10y ago

What are the important parts of the PvP and why are they important?

mightybyte 10y ago

The whole PVP debate really boils down to one simple question. Do you believe that a properly functioning dependency solver is important for the community? If you answer yes, then I think it's pretty straightforward to get from there to the conclusion that version bounds are necessary. And by the contrapositive, if you are arguing against upper bounds, then you are actually arguing against the usefulness of a solver. If you answer no, then we should debate the merits of having a solver.

massysett 10y ago
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? If I'm using `text`, and all I use from that package is `pack`, `unpack`, and `cons`, I shouldn't have to specify bounds. The Cabal way of doing this--specifying version bounds--creates a big maintenance burden. And even then, it does not always work. So yes, I would question the merits of having a solver that checks some version numbers that developers manually put in. That said, I lack the know-how or resources to come up with anything new, so I'm stuck using curation or a solver. Using someone else's curation winds up being much less work for me than using a solver, so that's what I do.
- hvr_ 10y ago
  > 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?
  - massysett 10y ago
    dcoutts said it would not be appropriate to change Hackage to require upper bounds on software. It would be quite simple to change Hackage so that any upload would require upper bounds restricted only to package versions that already exist. Why has no such change been made? If I were in your situation I would not be spending time on menial work when a simple program could prevent that work. If such a change were made I would happily stop uploading to Hackage altogether. That no such change has been made suggests there is insufficient support for your position. I have not wasted any trustee's time, as all my software works and I keep it working or mark it deprecated. That said, I do not want trustees to fix my stuff. I have no desire to waste anyone's time. The only reason I upload to Hackage is to get stuff into Stackage. I would fully support a way to get stuff into Stackage that skips Hackage. I think it would reduce a lot of this friction. However I can understand why Stackage has no such method: Hackage allows no upper bounds. This suggests that people value a large unfragmented Hackage more than they value required upper bounds. Of course I have no role in telling you how to spend your time, but if I were you I would stop fixing software that does not play by your preferred rules.

hvr_ 10y ago

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