Tentatively support Servant 0.11

[adinapoli-iohk]

Hey @jkarni & @alpmestan!

This PR tentatively adds support for Servant 0.11. As I am in "I don't know what I'm doing" mode, it's totally possible that the HasGenRequest EmptyAPI instance is totally rubbish 😀 .

I have also added a stack-lts-9.yaml manifest to allow building with GHC 8.x.

Let me know if this has any hope of landing on master and if there is a better way of writing such instance which does not require error 😞

[alpmestan]

Hello @adinapoli-iohk :)

People use EmptyAPI when they're stubbing a web API, filling individual endpoints or entire sub-APIs with EmptyAPI, until the said part is taken care of made more precise. It's a bit like GHC's holes really.

Given this context, I'd say that trying to test an EmptyAPI could result in two different reasonable behaviors:

• don't, simply skip it, or
• error out, like your PR does

I'd say that by the time you use servant-quickcheck on your API, you probably don't want any EmptyAPI left. In which case it makes sense to error out. @jkarni what do you think?

[phadej]

I hope that weight: 0 does make tester skip that "endpoint".

Note that servant-client just puts dummy value there: http://hackage.haskell.org/package/servant-client-0.11/docs/src/Servant-Client.html#line-105

IMHO for now it's good enough with error. Later we could consider some better accumulator than Gen a (i.e. something Monoidal).

[phadej]

Also: I do use EmptyAPI in production code. I have variants on FoldAPI (defs :: [*]) :: * type-family. Super useful.

[adinapoli-iohk]

I hope that weight: 0 does make tester skip that "endpoint".

I would hope that as well. I don't want to be the subject of any programmer-induced curses when the code blows up whilst running the specs 😅

[jkarni]

I think a weight of 0 is the right approach. Aside from adding the new stack file to travis.yaml, could you also add an entry to the changelog mentioning supporting newer servants?

[jkarni]

Could you add this to .travis.yaml?

[adinapoli-iohk]

@jkarni All done! (Unless I have screwed up, ofc 😀 )

Note how I haven't bumped the version in the .cabal manifest, as every project seems to follow its own convention (bump as part of the PR, do not bump, etc) so I have chosen neutrality here, but shout if you guys want me to bump it.

[coveralls]

Changes Unknown when pulling 199f6cc on adinapoli-iohk:support-servant-0.11 into ** on haskell-servant:master**.

[alpmestan]

Also: I do use EmptyAPI in production code.

😱

More seriously, that settles the issue. Skipping by giving a weight of 0 it is!

[jkarni]

Thanks!

[jkarni]

Released as 0.0.3.1.

[phadej]

https://pvp.haskell.org

Non-breaking change. Otherwise, if only new bindings, types, classes, non-orphan instances or modules (but see below) were added to the interface, then A.B MAY remain the same but the new C MUST be greater than the old C. Note that modifying imports or depending on a newer version of another package may cause extra non-orphan instances to be exported and thus force a minor version change.

[phadej]

if we act fast, we can make 0.0.3.1 a mistake by adding base < 0 bound.

[jkarni]

Wait what? The instance was always there, but you couldn't see it because the CPP condition for it (servant > 0.11) was always false! 😛

[jkarni]

More seriously: I'll bump to 0.4 then and base < 0 it.

[jkarni]

@phadej you're the expert in good Hackage-denizenship: any objections to making a 0.1.0.0 now so we're not constantly bumping the largest non-zero version number (e.g. #33 would be another one)?

[phadej]

@jkarni ah true, falsy alarm. We couldn't ever define that instance before (as an orphan elsewhere). Still feels fishy to have non-trivial changes in patch number. I over-reacted.

About 0.1.x vs 0.0.x: PVP doesn't give any meaning to the leading zeros, so as far as we don't introduce breaking changes, we don't need to bump second digit. I'd even say we shouldn't, to indicate that we don't break anything, only grow the functionality.

I'd like to talk about various practices, but that's better to do over a beer.

[adinapoli-iohk]

Thank you guys for the release and wow, that's a pleasure to see somebody actually try to enforce PVP -- too many times I have seen arbitrary bumps in libraries out there 😛