Various improvements

[blackheaven]

Hello,

I have seen your project during ZuriHac, and I have been quite busy in the mean time, I have finally find some for another project of mine and I make use of it.

This PR packs up few improvements:

• The naming was incorrect (the cabal file was not the right one and module names was not matching)
• It introduced stack
• It adds Hspec support

I also take the opportunity to do some suggestions:

• use hpack
• publish it on hackage

Do not hesitate to ask for changes.

[alexbiehl]

Thank you Gautier! This is looking great!

[alexbiehl]

Regarding release on hackage, do you have a sense of what still needs to happen for a 0.1 release? Here are a few random things that come to mind

• I suggest at least getting rid of all the undefines (either by implementing or getting rid of them) should be resolved.
• Also I think we should make run wait for the container to come up and put the WaitUntilReady check into the ContainerRequest
• Also put ToImage into the ContainerRequest to have it fully self-contained
• Proper error handling for the Docker process invocations

Let me know if you have suggestions and/or want to spend time on anything so that we can divide the workload.

Also thanks again for the PR much appreciated!

[blackheaven]

Cool, yes, nice ideas, I will have few more:

• Add a wrapper around docker inspect
• Add basic information fetching (for example, here is how I fetch the IP)

[alexbiehl]

Makes sense! Also I think it makes sense to add a WaitUntilReady that blocks until the container listens on some defined port. That should eliminate your threadDelay usage.

[alexbiehl]

Hey @blackheaven, I addressed all the points. Do you mind taking a look at the master branch and see if there is anything obviously missing?

[blackheaven]

Great, two last points:

• rename id to containerId
• have a log-based wait strategy, see (this code)[https://github.com/blackheaven/hermes/blob/master/test/Control/Hermes/RabbitMQUtils.hs#L111]

IMO you are good to publish it on hackage.

[alexbiehl]

• rename id to containerId

Do you think I should prefix every field of Container with container or just id?

• have a log-based wait strategy

FWIW we have waitForLogLine:

wairForLogLine Stdout (" completed with " `LazyText.isInfixOf`)

[alexbiehl]

Your example would boil down to something like

containers :: MonadDocker m => m (Channel, Channel)
containers = do
  let (login, password) = ("guest", "guest")

  container <- run $ containerRequest (fromTag "rabbitmq:3.8.4")
    & setExpose [5672]
    & setWaitingFor (waitForLogLine (" completed with " `LazyText.isInfixOf`))

  connection <- liftIO $ openConnection (containerIp container) (containerPort container 5672) "/" login password

  (,)
    <$> liftIO (openChannel connection)
    <*> liftIO (openChannel connection)

[blackheaven]

Do you think I should prefix every field of Container with container or just id?

every field

FWIW we have waitForLogLine:

I have missed it, that's awesome!

[blackheaven]

A last set of remarks:

• dependencies bounds does not match to any stable stack stable release
• relying on lens seems a bit heavy for your usecase

[alexbiehl]

dependencies bounds does not match to any stable stack stable release

What does that mean? How would I check against those?

relying on lens seems a bit heavy for your usecase

I agree. It made for such beatiful traversal of the JSON stuff.

[blackheaven]

dependencies bounds does not match to any stable stack stable release

What does that mean? How would I check against those?

Just configure stack with lts-16.8 you'll get:

In the dependencies for testcontainers-0.1.0.0:
    lens-4.18.1 from stack configuration does not match >=4.19.2 && <5  (latest matching version
                is 4.19.2)
    network-3.1.1.1 from stack configuration does not match >=2.8.0 && <2.9  (latest matching
                    version is 2.8.0.1)
    unliftio-core-0.1.2.0 from stack configuration does not match >=0.2.0 && <0.3  (latest
                          matching version is 0.2.0.1)
needed due to amqp-streamly-0.2.0 -> testcontainers-0.1.0.0

Some different approaches to resolving this:

  * Set 'allow-newer: true'
    in /home/black/.stack/config.yaml to ignore all version constraints and build anyway.

  * Recommended action: try adding the following to your extra-deps
    in /home/black/programmation/haskell/amqp-streamly/stack.yaml:

- lens-4.19.2@sha256:f0570ca0e4624d9daa57256f00f514e87be155401583fa1665faba47376c63a7,16053
- network-2.8.0.1@sha256:0f165dffa752d8cde30c2bde86f80609c4f1dc5eeb3182d593041f97839c5b3b,3011
- unliftio-core-0.2.0.1@sha256:9b3e44ea9aacacbfc35b3b54015af450091916ac3618a41868ebf6546977659a,1082

Plan construction failed.

relying on lens seems a bit heavy for your usecase

I agree. It made for such beatiful traversal of the JSON stuff.

I thought there were a optics-aeson library :/

[alexbiehl]

Are you able to provide better bounds? I don't have stack installed and all. If you know how to get to it it would be cool if you provided them. I will look at it eow else.

Oh, optics-aeson sounds promising. Will switch to that, thanks!

[blackheaven]

Yes and yes, I am on it (better bounds and optics-aeson)