Closed mpickering closed 8 years ago
snoyberg
commented
8 years ago 
mpickering
commented
8 years ago Hello Michael, thanks for your quick reply. I think it is a bug if I can't install something in the normal manner especially when the README doesn't indicate I should do it any other way. It seems that added a stricter version bound might make the package easier to install?
I don't use stack as I often use custom builds of GHC, using these with stack is not easy in my experience. It is also a pain that stack insists on managing my installation of GHC (for example installing GHC 7.10.3 in it's own sandbox when I already have it on my path just not as ghc).
snoyberg
commented
8 years ago I suggest you read a little more on Stack, your assumptions are incorrect. In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
mpickering
commented
8 years ago I fail to see what assumptions I am making, I am just reporting on my experiences.
That being said, it doesn't look like we are going to make any progress with the issue here so I will close this issue.
snoyberg
commented
8 years ago Stack doesn't insist on installing its own GHC, it will automatically use whatever GHC is on the path if available. That's the assumption I was referring to.
hvr
commented
8 years ago @snoyberg
In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
What "incorrect" information are you talking about? If there is a concrete bug in cabal, I'm very interested to know so it can be fixed. However, the only incorrect information I can see (maybe I'm missing something?) is packages like stackage-install containing incorrect build dependencies.
Specifically, stackage-install-0.1.1.1 says it needs http-client >= 0.4. But with http-client-0.5.0, you run into
Preprocessing library stackage-install-0.1.1.1...
[1 of 1] Compiling Stackage.Install ( Stackage/Install.hs, /tmp/stackage-install-0.1.1.1/dist-newstyle/build/stackage-install-0.1.1.1/build/Stackage/Install.o )
Stackage/Install.hs:46:61-71: error:
Module ‘Network.HTTP.Client’ does not export ‘checkStatus’Turns out, checkStatus was removed in http-client-0.5; so the accurate build-dep specification would have been http-client == 0.4.*.
If you choose not to follow the PVP by leaving off upper bounds, then please don't blame cabal-install 's solver for believing the inaccurate information you feed it. Moreover, for packages uploaded to Hackage, the desired base-line is compile-ability with cabal-install, and it's stated on Hackage's front page that we expect packages to follow the PVP. Maybe this needs to be made more visible?
snoyberg
commented
8 years ago Herbert, I really don't need to jump into these discussions with you constantly, you've already demonstrated that you're happy to pick a PVP fight wherever possible. My comment was that there's no problem demonstrated in this package, only in dependencies, and adding a workaround here is catering to a workflow which I believe to be broken by adding an incorrect bound. Your comment ignores the actual thread of conversation.
As it happens, I didn't notice the stackage-install build failure initially, and ended up removing that dep for unrelated reasons.
This rubbish of needing to be compatible with cabal-install because the Hackage overseers have stated it just makes me want to stop working with Hackage. Maybe you should take a step back and consider whether you want to continue being part of the problem with encouraging further fractures in our community.
On Sat, Jul 16, 2016, 12:43 AM Herbert Valerio Riedel < notifications@github.com> wrote:
@snoyberg https://github.com/snoyberg
In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
What "incorrect" information are you talking about? If there is a concrete bug in cabal, I'm very interested to know so it can be fixed. However, the only incorrect information I can see (maybe I'm missing something?) is packages like stackage-install containing incorrect build dependencies.
Specifically, stackage-install-0.1.1.1 says it needs http-client >= 0.4. But with http-client-0.5.0, you run into
Preprocessing library stackage-install-0.1.1.1... [1 of 1] Compiling Stackage.Install ( Stackage/Install.hs, /tmp/stackage-install-0.1.1.1/dist-newstyle/build/stackage-install-0.1.1.1/build/Stackage/Install.o )
Stackage/Install.hs:46:61-71: error: Module ‘Network.HTTP.Client’ does not export ‘checkStatus’
Turns out, checkStatus was removed in http-client-0.5; so the accurate build-dep specification would have been http-client == 0.4.*.
If you choose not to follow the PVP by leaving off upper bounds, then please don't blame cabal-install 's solver for believing the inaccurate information you feed it. Moreover, for packages uploaded to Hackage, the desired base-line is compile-ability with cabal-install, and it's stated on Hackage's front page that we expect packages to follow the PVP. Maybe this needs to be made more visible?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/fpco/stackage-curator/issues/22#issuecomment-233118149, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBBytyt2eHDY6U8vfnRpVm2pulzKBeks5qWIuugaJpZM4JNlCD .
edsko
commented
8 years ago In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
I have to admit to being confused. I thought the primary objection was against pre-emptive upper bounds, which are difficult to get right, make it hard to upgrade packages, lead to unnecessary failed install plans, etc. But in this case stackage-install does not build with version 0.5 of http-client. Even if you nonetheless think that an upper bound is not the right solution to this ("it's guaranteed to work with Stackage version such-and-such"), calling the upper bound "incorrect" and cabal's failure to somehow magically figure out that version 0.5 is not suitable a "bug" is rather disingenuous. Not to mention that referring to @hvr as "being part of the problem", with all the work he puts in to the build matrix, ghc Ubuntu packages, and countless other things for the community without being paid a penny for them, is completely uncalled for.
snoyberg
commented
8 years ago Look, if you just want to have another PVP and cabal party, go do it elsewhere. If you want to reread what issue tracker you're discussing this on, what was proposed, and what I rejected, and then admit that your comments are just completely off base, that'd be nice. But I'm not exactly holding my breath on any of that.
On Sun, Jul 17, 2016, 9:40 PM Edsko de Vries notifications@github.com wrote:
In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
I have to admit to being confused. I thought the primary objection was against pre-emptive upper bounds, which are difficult to get right, make it hard to upgrade packages, lead to unnecessary failed install plans, etc. But in this case stackage-install does not build with version 0.5 of http-client. Even if you nonetheless think that an upper bound is not the right solution to this ("it's guaranteed to work with Stackage version such-and-such"), calling the upper bound "incorrect" and cabal's failure to somehow magically figure out that version 0.5 is not suitable a "bug" is rather disingenuous. Not to mention that referring to @hvr https://github.com/hvr as "being part of the problem", with all the work he puts in to the build matrix, ghc Ubuntu packages, and countless other things for the community without being paid a penny for them, is completely uncalled for.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/fpco/stackage-curator/issues/22#issuecomment-233227668, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBB9cfPi3CMIiGHxfafneRB4P8ROJbks5qWwPLgaJpZM4JNlCD .
ekmett
commented
8 years ago In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
Not looking to rekindle any flame wars, just comment:
The item you are looking for in the module was actually concretely removed; this isn't a request for a pre-emptive bound, but rather for a retroactive one to match an actual issue. It seems to me that it is incorrect to state that it works with http-client >= 0.4, as once you hit 0.5 it demonstrably stops working again.
PVP aside, it is a bad bound. This is precisely the sort of "hard" upper bound for a real issue that I'd always thought you were willing to acknowledge had a place in the past.
snoyberg
commented
8 years ago @ekmett If you look through the history of what is being discussed here, you may see that there's just been a massive miscommunication - whether intentional or unintentional - going on here. As I said earlier:
As it happens, I didn't notice the stackage-install build failure initially, and ended up removing that dep for unrelated reasons.
The initial discussion was about stackage-curator and amazonka-core, where all of my claims make perfect sense: there's no reason why we should change something in stackage-curator to work around a bug in amazonka-core. Out of nowhere, Herbert jumped in to make a PVP claim about stackage-install. I have no problem with making that change (and, in fact, did so separately). My point the entire time was that this isn't a stackage-curator issue, and opening a bug report here or asking for changes to this repository is incorrect, and just playing to a cabal-install-specific bug workaround methodology that involves adding incorrect metadata.
I really have no idea how this relatively simple issue somehow invoked the ire of Herbert and Edsko, and where the brigading is coming from. But having it be so blatant that my comments are only being half-read isn't improving the impression I have of an attack brigade chomping at the bit.
ekmett
commented
8 years ago It does strike me as just everyone assuming bad faith on the part of everyone else. I think your comment:
I suggest you read a little more on Stack, your assumptions are incorrect. In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
got parsed as a refusal to put in the bound at all, not as saying this is the wrong place for the discussion, and with Herbert's little dig about the PVP at the end of his comment appeared to set you off in kind then everyone started talking past each other.
No brigade intended at least on my part, just well-meaning bafflement.
I can appreciate that once the issue was submitted to the correct issue tracker it was resolved immediately and I wish everyone here a happier day. =)
snoyberg
commented
8 years ago No brigading was taken on your part Edward. I am genuinely curious where these discussions of my actions must be occurring whereby Herbert and Edsko both suddenly popped up out of nowhere, but I don't think I'll be getting an answer on that front.
On Tue, Jul 19, 2016, 6:21 PM Edward Kmett notifications@github.com wrote:
It does strike me as just everyone assuming bad faith on the part of everyone else. I think your comment:
I suggest you read a little more on Stack, your assumptions are incorrect. In any event, I'm really not planning on catering to cabal-install's bug workarounds by putting incorrect information into cabal files (which is what would be necessary here).
got parsed as a refusal to put in the bound at all, not as saying this is the wrong place for the discussion, and with Herbert's little dig about the PVP at the end of his comment appeared to set you off in kind.
No brigade intended at least on my part, just well-meaning bafflement.
I can appreciate that once the issue was submitted to the correct issue tracker it was resolved immediately and I wish everyone here a happier day. =)
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/fpco/stackage-curator/issues/22#issuecomment-233813271, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBB6ogWj3Kda28qspCmS_bQ48AFNAIks5qXXghgaJpZM4JNlCD .
The package fails to build when I try to build it with GHC 8.0. I had to restart the build in the middle but
amazonka-core-1.4.3fails to install.