Closed Sciencei closed 5 years ago
@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.*
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.
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.
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.
any news on this ?
@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.
@alpmestan Sorry it took me a while to get to it, but the conflict has been resolved.
Some more conflicts to resolve I'm afraid :/
This is otherwise looking pretty good!
@alpmestan resolved this set of conflicts
This adds servant client support, with some caveats (at the end)
Additions
ToMultipart
to turn a data type into aMultipartData
genBoundary
to generate a boundary for a multipart requestmultipartToBody
converts aMultipartData
to a request body—separated out to so people doing custom combinators don't need to redo itHasClient
instances forMultipartForm
. The client functions take a tuple of a bytestring and the actualToMultipart a => a
and set the request body and content-type headers appropriatelyDependencies on
array
andrandom
, for the boundary generationDependency on
servant-client-core
for obvious reasonsChanges
MultipartBackend
now has aloadFile
function, to convert from aMultipartResult
to aSourceIO Bytestring
Upload
was changed to send the request using the new client backend rather than using http-client directlyCaveats
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
newtype
d so it can't be confused for an arbitrary bytestring?