MockService blocks test execution if pact-python is installed in system Python's site-packages

[fabianbuechler]

Package versions:

• pact-python 0.14.0
• Python 3.6.3 from official docker image

When installing pact-python into system-Python's site-packages, which is quite common when using a docker container, the Mock-Service cannot be started if the Python tests in the docker-container are not executed with root permissions.

Basically I have a test that creates a pact.Consumer and then calls consumer.pact.start_service() to run the mock service within a pytest fixture. That's roughly equivalent to:

import pact

consumer = pact.Consumer('consumer').has_pact_with(
    provider=pact.Provider('provider'),
    host_name='localhost',
    mock_port=1234,
)
consumer.pact.start_service()

# Execute test here.
# Tests want to access the running mock-service.

consumer.pact.stop_service()

However, during consumer.service_start() the MockService tries to modify its Gemfile.lock which is located at /usr/local/lib/python3.6/site-packages/pact/bin/pact/lib.
When running the docker container without root permissions, this file cannot be modified.

pytest prints the error message when invoked with -s (no capture) flag:

There was an error while trying to write to Gemfile.lock. It is likely that 
you need to allow write permissions for the file at path: 
/usr/local/lib/python3.6/site-packages/pact/bin/pact/lib/vendor/Gemfile.lock

I posted a pull request (#72) for a related problem, which is that during the call to consumer.pact.server_start() the Pact._wait_for_server_start method retries a connection to the started MockService 15 times. With the implementation of urllib3.utils.retry.Retry with a backoff_factor of 0.1 that means 54 minutes wait time before the tests actually fail.

Thus it appears as if the tests would simply block. In combination with pytest's output capturing this was pretty hard to spot. :)

I don't really know Ruby, so I cannot tell why the Gemfile.lock has to be modified when starting the MockService. However, when installed as a vendored library of a global Python site-package, that doesn't work.
Maybe you could download the vendored ruby libs to a temporary / cache directory?

[bethesque]

I wasn't aware of this behaviour, so I did a quick google and found this: rubygems/bundler#5245

Try setting BUNDLE_FROZEN=1 as per this comment. If it works, we can get the environment variable added to the invocation from the python code.

[fabianbuechler]

@bethesque, thanks for the heads-up on that setting. I quickly tried it with the docker container and it works.

[fabianbuechler]

@bethesque, I've created a pull-request #74 for this.