Make the AGPL flag manual in cabal #250
Conversation
|
Cabal automatically tries all the possible combinations of non-manual flags when solving, leaving manual flags at their default value. I think we really want this flag to be non-manual, otherwise the Cabal build will fail in 8.10.1 where Brittany is not available |
|
yeah, auto makes cabal trying enable it to get a build plan so it must be manual |
|
@pepeiborra Brittany wasn't included for me for ghc 8.8.3 either, which is weird, since the default is Also, if Brittany does not exist for 8.10.1 yet, we should, as suggested in haskell/vscode-haskell#255, use a different default formatter, in my opinion. |
Really? I thought that cabal would use the default value first, and then if solving fails, try again with the negated default value if the flag is non manual. |
|
I have a lint check for my projects that all flags are set to Manual. I think of it was manual = for user. Otherwise = random hacks to encourage Cabal to find a build plan. |
I have no idea why, but you can ask cabal. I agree that Brittany is not a good default in 8.10.1 !! |
fendor
force-pushed
the
cabal-flag-agpl
branch
2 times, most recently
from
80775bf
to
7120a77
Compare
|
@pepeiborra the mysteries of the cabal plan algorithm are unfathomable 😝 |
I thought our default formatter is Am I missing something? |
|
@Ailrun the vscode plugin overrides this configuration |
|
That's... surprising 😮 Thank you for the answer :) |
|
It is surprising indeed, I've opened up a PR on vscode-haskell to change the default to ormolu to match up. Unless anyone has a stronger preference for another default? |
|
I think avoiding AGPL/GPL for default things is wise - it isn't a typical Haskell license. |
|
Exactly, we should coordinate. Whatever you decide in this is fine by me, but I would like to make this flag manual eventually. |
|
Ok we should merge this first then, this PR makes sense to me |
* Fix #248 and #250 This fixes hover for types, classes and type variables. Information about spans includes a `Maybe Type` which is `Just` for data-level expressions and `Nothing` for type-level expressions. `AtPoint.atPoint` which is the oddly-named function responsible for constructing hover information, runs in the `Maybe` monad, and aborted at the first sight of a `Nothing`, thus producing no hover information for type-level spans. In the process of fixing this, I have refactored the function to + separate the construction of data-level and type-level hover info + make the components that make up the hover info (and their construction) more clear I can see plenty little improvements that could be made to the functionality of the code (and lots that could be made to its organization), but the most important fixes of the basic missing functionality are here. Fix #248 Fix #250 * Revert behaviour of locationsAtPoint to match its name The name suggests that it returns all locations, while the last commit changed this to return at most one. * Fix issue numbers in test titles There was some confusion about which tests addressed issue 248 vs 249
I honestly don't know what this entails and the documentation is hard to find but I think it fixes the problem described in haskell/vscode-haskell#255