Add client support

[Sciencei]

This adds servant client support, with some caveats (at the end)

Additions

ToMultipart to turn a data type into a MultipartData

genBoundary to generate a boundary for a multipart request

multipartToBody converts a MultipartData to a request body—separated out to so people doing custom combinators don't need to redo it

HasClient instances for MultipartForm. The client functions take a tuple of a bytestring and the actual ToMultipart a => a and set the request body and content-type headers appropriately

Dependencies on array and random, for the boundary generation

Dependency on servant-client-core for obvious reasons

Changes

MultipartBackend now has a loadFile function, to convert from a MultipartResult to a SourceIO Bytestring

Upload was changed to send the request using the new client backend rather than using http-client directly

Caveats

• Passing in the boundary is awkward. The boundary needs to be randomly generated though, so I don't believe there's a way around this without changing RequestBody in servant-client-core.

• Clients and servers are forced to use the same backend if they use the same API specification. This isn't a huge deal since the API can be converted with a type family, but it feels awkward.

• Because this uses SourceT, it requires servant >= 0.16. Backporting should be possible if needed though.

• I don't know how much it's actually used, but multipart forms can have more than just files and plaintext, and this isn't really supported (in a pinch, it could be done hackily by hijacking the FileData list though).

• Possibly the boundary should be newtyped so it can't be confused for an arbitrary bytestring?

[alpmestan]

@phadej CI fails on this, with:

$ ${CABAL} new-build -w ${HC} --disable-tests --disable-benchmarks  --constraint='servant ==0.15.*' all
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: servant-multipart-0.11.4 (user goal)
[__1] next goal: servant (dependency of servant-multipart)
[__1] rejecting: servant-0.16 (constraint from command line flag requires
==0.15.*)
[__1] rejecting: servant-0.15 (conflict: servant-multipart => servant>=0.16 &&
<0.17)
[__1] rejecting: servant-0.14.1, servant-0.14, servant-0.13.0.1, servant-0.13,
servant-0.12.1, servant-0.12, servant-0.11, servant-0.10, servant-0.9.1.1,
servant-0.9.1, servant-0.9.0.1, servant-0.9, servant-0.8.1, servant-0.8,
servant-0.7.1, servant-0.7, servant-0.6.1, servant-0.6, servant-0.5,
servant-0.4.4.7, servant-0.4.4.6, servant-0.4.4.5, servant-0.4.4.4,
servant-0.4.4.3, servant-0.4.4.2, servant-0.4.4, servant-0.4.3.1,
servant-0.4.3, servant-0.4.2, servant-0.4.1, servant-0.4.0, servant-0.2.2,
servant-0.2.1, servant-0.2, servant-0.1 (constraint from command line flag
requires ==0.15.*)
[__1] fail (backjumping, conflict set: servant, servant-multipart)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: servant, servant-multipart
The command "${CABAL} new-build -w ${HC} --disable-tests --disable-benchmarks  --constraint='servant ==0.15.*' all" exited with 1.

I hardly see how this can work, since the .cabal file wants >= 0.16 and the constraint enforced there is ==0.15.*

[phadej]

We test with older servants too, see https://github.com/haskell-servant/servant-multipart/blob/master/cabal.haskell-ci

Sent from my iPhone

On 2 Apr 2019, at 12.57, Alp Mestanogullari notifications@github.com wrote:

@phadej CI fails on this, with:

$ ${CABAL} new-build -w ${HC} --disable-tests --disable-benchmarks --constraint='servant ==0.15.' all Resolving dependencies... cabal: Could not resolve dependencies: [0] trying: servant-multipart-0.11.4 (user goal) [1] next goal: servant (dependency of servant-multipart) [__1] rejecting: servant-0.16 (constraint from command line flag requires ==0.15.) [1] rejecting: servant-0.15 (conflict: servant-multipart => servant>=0.16 && <0.17) [1] rejecting: servant-0.14.1, servant-0.14, servant-0.13.0.1, servant-0.13, servant-0.12.1, servant-0.12, servant-0.11, servant-0.10, servant-0.9.1.1, servant-0.9.1, servant-0.9.0.1, servant-0.9, servant-0.8.1, servant-0.8, servant-0.7.1, servant-0.7, servant-0.6.1, servant-0.6, servant-0.5, servant-0.4.4.7, servant-0.4.4.6, servant-0.4.4.5, servant-0.4.4.4, servant-0.4.4.3, servant-0.4.4.2, servant-0.4.4, servant-0.4.3.1, servant-0.4.3, servant-0.4.2, servant-0.4.1, servant-0.4.0, servant-0.2.2, servant-0.2.1, servant-0.2, servant-0.1 (constraint from command line flag requires ==0.15.) [__1] fail (backjumping, conflict set: servant, servant-multipart) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: servant, servant-multipart The command "${CABAL} new-build -w ${HC} --disable-tests --disable-benchmarks --constraint='servant ==0.15.' all" exited with 1. I hardly see how this can work, since the .cabal file wants >= 0.16 and the constraint enforced there is ==0.15.*

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Sciencei]

Should I just do a commit removing the servant 0.15 version from the CI config? Alternatively, like I said backporting should be doable (using CPP), but I'd like to make sure nothing else needs to be changed first, so I don't need to redo both the >= 0.16 version and the backported version.

[phadej]

Removing 0.15 is fine

Sent from my iPhone

On 3 Apr 2019, at 19.35, Sciencei notifications@github.com wrote:

Should I just do a commit removing the servant 0.15 version from the CI config? Alternatively, like I said backporting should be doable (using CPP), but I'd like to make sure nothing else needs to be changed first, so I don't need to redo both the >= 0.16 version and the backported version.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rsoeldner]

any news on this ?

[alpmestan]

@rsoeldner Sorry for the delay. The patch looks reasonable for a first implementation of client support. Could you resolve the conflict? I'll then make sure this lands.

[Sciencei]

@alpmestan Sorry it took me a while to get to it, but the conflict has been resolved.

[alpmestan]

Some more conflicts to resolve I'm afraid :/

This is otherwise looking pretty good!

[Sciencei]

@alpmestan resolved this set of conflicts