glabrous 0.2 requires outdated aeson

[snoyberg]

aeson-1.0.2.1 (Adam Bergmark adam@bergmark.nl @bergmark) is out of bounds for:

• glabrous-0.2.0 (>=0.11.2 && < 0.12). Michel Boucey michel.boucey@gmail.com @MichelBoucey. @MichelBoucey

aeson-pretty-0.8.2 (Joey Eremondi joey@eremondi.com @JoeyEremondi) is out of bounds for:

• glabrous-0.2.0 (>=0.7.2 && < 0.8). Michel Boucey michel.boucey@gmail.com @MichelBoucey. @MichelBoucey

[MichelBoucey]

But bounds are ok for LTS-6.1 build plan, isn't it? Well... certainly not for nightly builds. I'm gonna remove upper bounds for those two packages. I thought you wrote somewhere that it is better for Stackage to not put upper bounds (I just did add upper bounds because of cabal gen-bounds)... Am I wrong? But I saw in your repos that there is upper bounds. Is there a means to check the correctness of build plans till latest ones? Or just by trying?

[snoyberg]

I get crucified for anything I say about presence or absence of upper bounds, so I'll hold off on commenting. Stackage itself does not require bounds, but respects them if present.

The best way to check bounds automatically is via Travis. The standard Travis complex config from Stack (https://raw.githubusercontent.com/commercialhaskell/stack/master/doc/travis-complex.yml and https://docs.haskellstack.org/en/stable/travis_ci/) will build against:

• Multiple LTSes
• The current nightly
• On both Linux and OS X
• And do dep solving with cabal

So it's a pretty good stress test that your bounds are working for lots of cases. If you simply leave off the bounds, you'll never get bounds errors from Stack, but you may get compile errors instead.

[MichelBoucey]

That's what I had understood: no upper bounds, no Stack errors but possible futur build failures... So trying automatically with Travis. My travis config is too light. Thanks for Travis references... I'm gonna solve this issue asap...

[hvr]

Stackage itself does not require bounds

Putting my Hackage Trustee hat on: While technically true, Hackage's guidelines expect packages uploaded to Hackage to follow the PVP, see also this FAQ entry. A simple way to comply is to add pvp-bounds: both to your stack.yaml file.

[DanBurton]

My 2 cents: it is convenient for your users if your packages are able to build against the latest versions of all dependencies.

If you put upper bounds on your package, then we at Stackage will alert you when those upper bounds are "too low" and do not accommodate the latest version of any given dependency. This gives you the opportunity to make your package "human certified" that it works with the new version.

If you don't put upper bounds on your package, then we at Stackage will only alert you when a dependency upgrade causes a build or test suite failure. (We will alert you of this sort of thing in either scenario.)

I consider upper bounds to be good practice for maintainers with packages on stackage, as long as they are able to respond promptly to the alerts.

[snoyberg]

@hvr I already mentioned you above:

I get crucified for anything I say about presence or absence of upper bounds

Please stop following me around Github and taking every chance to make a speech about the PVP. I've heard them, and they're a waste of my time. If you want to give the speech to others individually, I don't care, let them be the judges of whether they want to ask you to stop. But I'm officially, and as clearly as possible, asking you to stop doing this.

[hvr]

@snoyberg I'm sorry if you feel "crucified" by what was merely meant as a succinct clarification of how Hackage policy relates to Stackage policy, and moreover this was mostly directed at those who aren't aware of that relationship yet (in other words, you aren't my target audience).

[snoyberg]

Having unrelated issues filled with the same discussions constantly wastes my time and makes it harder to deal with the issue at hand. If someone else is your target audience, talk to them. I'm asking you to take the rhetoric away from me.

…

On Wed, Dec 14, 2016, 8:49 PM Herbert Valerio Riedel < ***@***.***> wrote: @snoyberg <https://github.com/snoyberg> I'm sorry if you feel "crucified" by what was merely meant as a succinct clarification of how Hackage policy relates to Stackage policy, and moreover this was mostly directed at those who aren't aware of that relationship yet (in other words, you aren't my target audience). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2135 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBB_Yk26ByC5qfjJxTr5NhMvhrLRuPks5rIDo-gaJpZM4LMnG7> .

[hvr]

@snoyberg I would, but it's far more efficient to clarify incomplete information right at the source before it spreads, than having to contact each single package author individually, which would end up becoming a full-time job or rather a fool's errand...

[alanz]

Everyone. We know this is a problem. We have begun a process to try to get it resolved in a constructive way at haskell/ecosystem-proposals#1.

These kinds of conversations do not help, when they cover ground that has been covered many times before.

[MichelBoucey]

It's seems obvious to me, and I'm sure for everyone too, that upper bounds should be set, but I think we are taking about the "Upper Cabal Hell", and it is just easier for me to leave open upper bounds (it is also a good thing to ease build process to not discourage developpers by not putting upper bounds) . If an issue occur, as Dan said, I will just respond present! And if my packages becomes much popular, I will harden them.

This time I have 1°/ removed upper bounds (@hvr: I will try again to put upper bounds next time, I swear), 2°/ used the complex Travis config file to test much more build variants and it is much better now. It seems to me necessary and sufficient... And I will give a try to pvp-bounds: both.

(I try to do my best to learn and use this gem, Haskell, but all of you do much more than me and have a same goal which is to build a better Haskell ecosystem, isn't it? You are just trying to open different tracks : don't flame.)

[alanz]

@MichelBoucey Thanks. I think in the current state of the ecosystem adding pvp-bounds: both and being responsive to reports is the best we as a community can expect. And of course the complex travis build file.

[snoyberg]

@MichelBoucey Looks like this is resolved, thanks! New version of glabrous will be included in the next nightly.

[MichelBoucey]

@snoyberg Thanks.

@alanz I said I will give a try to pvp-bounds: both because I don't know yet its effects.

[MichelBoucey]

@snoyberg @hvr @alanz @DanBurton

I just released all my packages which are now PVP compliant and tested against complex Travis config. I have made bounds as lower and upper as possible.

[snoyberg]

@MichelBoucey FYI, the newest glabrous release introduced upper bounds on hspec, which you're about to get an issue filed about most likely.

[decentral1se]

#2183 ^^ 👍

[MichelBoucey]

@snoyberg My .cabal was rewritten (during stack sdist) by pvp-bounds: both which I have just added to my stack.yml... there was no bounds in test-suite packages. Is it possible to generate the .cabal before sdist to not have surprising rewritings?

[snoyberg]

I don't believe so, you'd have to `stack sdist`, grab the .cabal file, and move on from there.

…

On Wed, Jan 4, 2017 at 5:31 PM, Michel Boucey ***@***.***> wrote: @snoyberg <https://github.com/snoyberg> My .cabal was rewritten (during stack sdist) by pvp-bounds: both which I have just added to my stack.yml... there was no bounds in test-suite packages. Is it possible to generate the .cabal before sdist to not have surprising rewritings? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2135 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBBw0oDf8LfEkkm_MI0rBaiACmHBKhks5rO7tTgaJpZM4LMnG7> .