yaml-0.8.31 causes issues on GHC 7.10 and below #165
Comments
|
I'm having the same issue with my pandoc CI builds on ghc 7.10.3 + cabal 2.0. |
Looks like the main thing that changed was raising the minimum bound for base to 4.9.1 and the restriction to ghc >= 8.0.2. But as @ndmitchell says, it's hard to see why cabal's solver didn't just reject the package. @snoyberg is it impossible to continue to support ghc 7.10.3? We'll have to drop support for it in pandoc solely because of this package. [EDIT: Well, I suppose I can just put an upper bound on the package for older ghcs.] |
|
@jgm as long as Cabal solver is smart enough to pick an older version (which it isn't for no obvious reason), you can continue supporting 7.10.3 even if it results in using an older yaml. |
|
@ndmitchell the reason matrix.hho has black squares is that the construct The issues with @jgm btw, if you just need a standards compliant YAML 1.2 parser that avoids FFI and supports GHCs back till GHC 7.4, HsYAML is currently officially the most compliant YAML 1.2 parser available :-) |
|
@hvr perfectly happy with the yaml package, I just want it to install :) Is the advice that @snoyberg should avoid the |
|
@ndmitchell Old |
|
@hvr thanks for the pointer about HsYaml; I'd like to use a pure Haskell library if possible. I'll try it out. |
|
@phadej saying you can use GHC out the box if you upgrade all the things around it to me doesn't work - the people who are on old GHC are also on old Cabal and old cabal-install. |
|
@ndmitchell true enough, but upgrading from an older ghc is hard -- you may have a codebase which is not compatible library changes, other couplings, etc. On the other hand, updating (also: another, certainly nonideal, workaround, would be for the cabal files of their projects, which are likely proprietary, to simply just exclude the offending version of |
|
Before I make a release to Hackage, can someone confirm that this release will properly work around the bug in cabal-install? snoyberg/yaml@2735b09 |
|
And here's a workaround for http-client: snoyberg/http-client@1390d6e. |
|
Michael Snoyman <[email protected]> writes:
Before I make a release to Hackage, can someone confirm that this release will properly work around the bug in cabal-install? snoyberg/yaml@2735b09
If you add a cabal 2.0 + ghc 7.10.3 combination to
your travis CI testing, that should give you the answer.
|
|
@snoyberg unfortunately my CI is set up thus that it's almost impossible to test before release is made... If you do make it thought I can give quick feedback after that. |
Afaict it won't. The bug here is in the solver choosing the wrong version of the yaml package, but building a local package won't trigger that code path. I think I'll just move ahead with the release, do some Hackage revisions, and hope for the best. |
|
I've published a new version of yaml, and added the only revision I could that should fix this: totally breaking yaml-0.8.31 (http://hackage.haskell.org/package/yaml-0.8.31/revisions/). Can you both give it a try and let me know if it works? If so, I'll release http-client as well. |
Btw, for more or less obvious reasons that won't work due to how constraint solving works PS: And neither the revision at http://hackage.haskell.org/package/yaml-0.8.31/revisions/ will work PS2: It's better for you to not do anything to avoid making things worse; I'm looking into addressing this from a more direct and effective angle PS3: If something's unclear just ask here; there's no need to go complaining on Twitter; the short gist is that backtracking doesn't kick in for the same reason we're having this problem in the first place: once |
|
Let me expand a bit, because I had to work it through myself. If there were no version with the buildable flag set to false, but instead of that, an unsatisfiable constraint were used, things would be fine. However, the existence of such a version means that the solver, finding the current version not satisfiable, would backtrack to the bad version, and then encounter that buildable flag, and then go kaput. My immediate thought was "can't we just unprefer the bad version" but it turns out that's not as strong as we'd like, since unprefering is not a hard blacklist, but just makes the solver try the other paths first. So if you have something that pushes the solver past the working paths, then it still follows the failing path instead of recognizing it as a "fully" not working path. So we will try to work out a fix and sort this out, but the above approach, which does seem reasonable at first, isn't going to suffice. |
|
Would using base versions, skipping any ghc-version test in the Cabal file itself (as this seems to lead to a pot of despair), and then having the Hackage UI display GHC version bounds based on |
|
I don' t know what the best long-term approach is. We do have an older ticket suggesting that certainly hackage displaying the base <-> ghc mapping would be a good idea, regardless: haskell/hackage-server#559 |
|
@snoyberg I confirm empirically that it's still bust for me. |
This makes it possible to resolve issues such as haskell-infra/hackage-trustees#165 in a simple, direct, and effective way by using the well-proven Hackage meta-data revision facility.
|
Alright, the situation with As a side-remark, in general I'd advise against using the |
|
This was an invalid resolution to the situation with http-client: you have broken the most recent version of the package, which people are using, and without a new version to replace it. I do not agree to these kinds of changes to my packages being made, especially without even the courtesy of an explanation being made in this discussion as to what changes you made to my package. I'll clean this one up myself by uploading a new version of http-client. But the fact that the only version of a package of mine adding features people are using was deprecated via a revision without any explanation that that was your plan is pretty unsettling. |
|
I think this was just a miscommunication. Since you had uploaded a new yaml and attempted to make the prior one unbuildable, I think it was expected the same process would be taken with http-client. I agree that for clarity's sake, it would have been better to handle yaml, and then leave it to you to handle http-client following the same template. |
|
I was quite explicit about my intentions and my actions:
The issue here was that a Hackage Trustee—@hvr—felt it appropriate to tell me to stop maintaining my own packages and performed surgery on them without any explanation of the process being taken. This is precisely why the revision mechanism is so disliked by so many. This is an upsetting combination of unacceptable communication style and the disregard for breakage caused to users by actions. I highly recommend the Hackage Trustee team and haskell.org committee address these concerns, which have been regularly raised and continue to be a major issue. |
|
Yes you were explicit, which is why this was a miscommunication and misunderstanding. I am glad we had this chance to resolve it to everyone's satisfaction. |
I have not; please get your facts straight before jumping to false conclusions; next time, please ask if there's something you don't understand |
|
To expand (and here it seems like more misunderstanding and miscommunication): I don't think the revision made broke the then-most-recent version (0.5.13). Looking at http://hackage.haskell.org/package/http-client-0.5.13/http-client.cabal it just seems like it swapped out the not-working buildable thing in the build-depends for the correctly-working base < 0 thing, which should not have broken the package for people. |
|
It looks like I misread the edit, that's my mistake. All of my other statements stand: this was handled in an unacceptable way, and needs to be addressed by improved processes. Gershom's comment "to everyone's satisfaction" is certainly not true, there is no satisfaction on my side from the behavior of the official haskell.org representatives and Hackage/Cabal maintainers present here. Unfortunately the only people to appeal to appear to be the people misbehaving. |
|
Also, for the record, the reason I got this wrong is that the revision display on Hackage strongly implies that
|
|
Considering this issue is resolved, I move that the discussion be taken elsewhere. |
|
I've opened up an issue for the incorrect revisions display: haskell/hackage-server#770. |
I'm sorry that you feel that way but as history has shown it's difficult to meet your demands and when things aren't done 100% as requested you seem to resort to personal attacks and ad-hominems (like e.g. two years ago just as one of several examples). I stayed up late last night to fix |
|
I don't want to heat up this discussion more than needed, but @snoyberg would using |
|
@domenkozar Yeesh, didn't think of that. Definitely not ideal. As a workaround, can we add |
|
@domenkozar I'm willing to change the cabal file, but I think you're going to have bigger problems than this. The "include a package name as a dependency and the package doesn't exist" approach was cribbed from base: I'd rather move this discussion away from this issue though. If you want to follow up, please do so on the yaml repo instead. |
0.11.2.0
* Reduces some of the code duplication between the encode and
encodePretty functions
* The output of encodePretty has been improved:
* Multiline strings now use Literal style instead of SingleQuoted
* Special keys are now quoted in mappings #179
* Support for complex keys in mappings: #182
* Adds complexMapping function to Data.Yaml.Builder
* Decode functions now return a NonStringKey error when attempting
to decode a mapping with a complex key as it is not possible to
decode these to an Aeson Value
* Adds missing ToYaml instances
0.11.1.2
* Compiles with GHC 8.8.1 (MonadFail split)
0.11.1.1
* Use the appropriate Scientific rendering function to avoid a memory
overflow when rendering. The previously used function from aeson
would not use scientific notation, and could use large amounts of
memory for values such as 1e9999999999999.
0.11.1.0
* Better error messages in the Data.Yaml.Config module #168
* Add LoadSettingsException exception and remove error printing from
loadYamlSettings #172
0.11.0.0
* Split out the libyaml and Text.Libyaml code into its own
package. #145
0.10.4.0
* Add decodeMarked and decodeFileMarked functions to Text.Libyaml, and
extend native bindings to extract mark information. #157
0.10.3.0
* Add support for anchors and aliases to Data.Yaml.Builder #155
* Fix test suite for 32 bit machines #158
0.10.2.0
* Add EncodeOptions and FormatOptions to control the style of the
encoded YAML. #153
* Default to using literal style for multiline strings #152
0.10.1.1
* Correctly declare libyaml dependency on system-libyaml flag #151
0.10.1
* Avoid incurring a semigroups dependency on recent GHCs.
* Fix a space leak that was introduced with 0.10.0 #147
0.10.0
* Add decodeFileWithWarnings which returns warnings for duplicate
fields
0.9.0
* Expose style and tags on mappings and sequences in Text.Libyaml #141
0.8.32
* Escape keys as necessary #137
* Support hexadecimal and octal number values #135
* More resilient isNumeric (should reduce cases of unneeded quoting)
* hpackify
* src subdir
0.8.31.1
* Add a workaround for a cabal bug haskell-infra/hackage-trustees#165
0.8.31
* Add decodeThrow and decodeFileThrow convenience functions.
* Upgrade libyaml versions
* Deprecate decode and decodeEither
0.11.2.0
* Reduces some of the code duplication between the encode and
encodePretty functions
* The output of encodePretty has been improved:
* Multiline strings now use Literal style instead of SingleQuoted
* Special keys are now quoted in mappings #179
* Support for complex keys in mappings: #182
* Adds complexMapping function to Data.Yaml.Builder
* Decode functions now return a NonStringKey error when attempting
to decode a mapping with a complex key as it is not possible to
decode these to an Aeson Value
* Adds missing ToYaml instances
0.11.1.2
* Compiles with GHC 8.8.1 (MonadFail split)
0.11.1.1
* Use the appropriate Scientific rendering function to avoid a memory
overflow when rendering. The previously used function from aeson
would not use scientific notation, and could use large amounts of
memory for values such as 1e9999999999999.
0.11.1.0
* Better error messages in the Data.Yaml.Config module #168
* Add LoadSettingsException exception and remove error printing from
loadYamlSettings #172
0.11.0.0
* Split out the libyaml and Text.Libyaml code into its own
package. #145
0.10.4.0
* Add decodeMarked and decodeFileMarked functions to Text.Libyaml, and
extend native bindings to extract mark information. #157
0.10.3.0
* Add support for anchors and aliases to Data.Yaml.Builder #155
* Fix test suite for 32 bit machines #158
0.10.2.0
* Add EncodeOptions and FormatOptions to control the style of the
encoded YAML. #153
* Default to using literal style for multiline strings #152
0.10.1.1
* Correctly declare libyaml dependency on system-libyaml flag #151
0.10.1
* Avoid incurring a semigroups dependency on recent GHCs.
* Fix a space leak that was introduced with 0.10.0 #147
0.10.0
* Add decodeFileWithWarnings which returns warnings for duplicate
fields
0.9.0
* Expose style and tags on mappings and sequences in Text.Libyaml #141
0.8.32
* Escape keys as necessary #137
* Support hexadecimal and octal number values #135
* More resilient isNumeric (should reduce cases of unneeded quoting)
* hpackify
* src subdir
0.8.31.1
* Add a workaround for a cabal bug haskell-infra/hackage-trustees#165
0.8.31
* Add decodeThrow and decodeFileThrow convenience functions.
* Upgrade libyaml versions
* Deprecate decode and decodeEither
I'm seeing this on Travis for HLint: https://travis-ci.org/ndmitchell/hlint/builds/397826785
And the Hackage matrix is showing black squares: https://matrix.hackage.haskell.org/package/yaml
CC @snoyberg. Looking at the code, it has a lower bound on base of GHC 8, so not sure what the problem is...
The text was updated successfully, but these errors were encountered: