We re-export everything under Docker so a user can just use
"import Docker" and get everything that they need. But the core
of the library lives under the Docker.Client namespace.
...leaving the original commit messages below:
- Docker.Http compiles
- preliminary updates
- Using requestHelper for a few more functions
- check expected status codes for a given endpoint
- split up requestHelper by adding parseResponse. Updated create opts for
docker api 1.24
- DockerT instances
- outline for inspect container. fixed some warnings
- generalize http handlers
- monadio instance
- switch to statusCodeToError from expectedStatusCode
- added tlssettings for client auth
- small change
- hide constructors for ContainerID and ImageID
- preliminary whitelist for ImageID and ContainerID
- types for container details and network settings
- include HostConfig and NetworkSettings in ContainerDetails
- some aeson instances
- more aeson instances
- Implemented getContainerLogs
- some aeson instances
- more aeson instances
- more aeson instances
- Re-export some functionality and hide others
- rewrote tests for new api
- added supported ciphers for ssl
- tests for ssl
- ability to set CA
- takes care of #10
- use CA in tests
Squashing more commits from both myself(Deni) and James into this one:
- Get rid of compiler warnings
- Mostly just unused imports and such.
- Removes old commented out code
- Adds defaultCreateOpts
and some automatic style changes.
- Use local docker daemon in tests
(for now without tls...)
- send POST bodies
- Sets application/json headers expliclty.
- Makes tests pass.
- Added ExposedPorts data type. Removed some manual
to/from json instances in favour of ones generated by generics.
- Adds more json instance
mostly pertaining to HostConfig
- Removes Storage driver options from HostConfig
It's unclear from the docs and the go code how this is to be used
and what it's for.
- Adds a better way to serialize CreateOpts
I've changed my mind about this. I want the functions to be total
and return Either DockerError a. After some thinking, I don't think
the ExceptT IO antipattern pertains to this case becuase ExceptT isn't
exposed to the user rather the user get's Either Error a. The only one
who'll see the ExceptT are the libray maintainers.
The idea is to catch all the relevant exceptions in the defaultHttpHandler
so that the user doesn't have to care that they are dealing with a HTTP Api
because that's totally an implementation detail.
I realize that I'm sort of going the catch-all/mask-all road here but
I will only handle the most common cases to abstract away that we're
talking to Docker over a remote http api. I won't mask all, ie. I won't
catch SomeException and therefore break async exceptions that way.
For 99% of the cases this should be fine but for more advanced users
there's always the option of building their own httpHandler to handle
whatever special use-case they might have and the functions won't care
because they are polymorphic Monad wise.
From what I read
here: https://www.schoolofhaskell.com/user/commercial/content/exceptions-best-practices
wrapping IO in ExceptT is considered an antipattern.
Instead we're using MonadThro.
Also we generalize our functions to accept any Monad that has an instance of MonadThrow.
This allows us to supply a httpHandler that runs in another Monad
and not just IO.
and add port binding (which have a different structure
than the actual PortBinding while creating the container yay.)
also add returning of atleast of ContainerID on the endpoints that
return nothing. At least this way we can pipe stopContainer back
into startContainer without providing the contianer id in 2 places.
