TypeError: _make_request() got an unexpected keyword argument 'use_get' about python-epo-ops-client HOT 16 CLOSED

Will check this out shortly.

from python-epo-ops-client.

Thanks!

from python-epo-ops-client.

@amotl Hmm, I couldn't reproduce this:

In [20]: from epo_ops import Client

In [21]: from epo_ops.models import Docdb

In [22]: c = Client('key', 'secret')

In [23]: response = c.family("publication", Docdb("1000000", "EP", "A1"), constituents=['biblio
    ...: ', 'legal'])

In [24]: response.status_code
Out[24]: 200

Does that match your expectation?

from python-epo-ops-client.

Thanks, I will check this again.

from python-epo-ops-client.

After pulling the most recent changes from development, I can confirm all tests are succeeding

pytest -s -v --cov-report term --cov epo_ops tests

especially the tests added to cover the topic #33/#34.

tests/test_api.py::test_family[default_client] PASSED
tests/test_api.py::test_family_biblio[default_client] PASSED
tests/test_api.py::test_family_legal[default_client] PASSED

So, I am puzzled why PatZilla would croak on that. Investigating...

However, those two guys fail

tests/test_ops_quota.py::test_mock_quota_exceeded[cached_client] FAILED
tests/test_ops_quota.py::test_mock_quota_exceeded[default_client] FAILED

which is totally unrelated to this issue, so this is just FYI.

from python-epo-ops-client.

@amotl In order to successfully execute the mock tests, you'll need to get an apiary URL as specified in https://github.com/55minutes/python-epo-ops-client#tests.

from python-epo-ops-client.

You can always refer to travis as well.

from python-epo-ops-client.

In order to successfully execute the mock tests, you'll need to get an apiary URL

I see, thanks. I was running them against production by using

export APIARY_URL=https://ops.epo.org/

from python-epo-ops-client.

@amotl Can you try APIARY_URL=http://private-anon-111333769e-opsv31.apiary-mock.com?

from python-epo-ops-client.

That works perfectly and also makes the mock tests pass. Thanks!

However, regarding the subtle change required from #33/#34, we obviously preferred running the tests against the real API.

As we see everything should be fine with python-epo-ops-client in this regard, we will now check what might be going wrong with the integration into PatZilla.

from python-epo-ops-client.

@amotl Only the EPO failure cases (quota exceeded per day/week) hit the mock API url, as there's no way to simulate that directly at OPS (they don't have a staging server with failure simulation URLs, as far as I know). Everything else hits the actual OPS end points, that's why the OPS key and secret is required for testing.

from python-epo-ops-client.

You can see what Apiary mocks: https://opsv31.docs.apiary.io/.

Also thanks for testing, I'll document the anonymous URL in the project docs.

from python-epo-ops-client.

Only the EPO failure cases (quota exceeded per day/week) hit the mock API url.

Thank you very much for letting us know about this important detail. So, there's no reason not to run the tests against the Apiary endpoint.

from python-epo-ops-client.

Regarding the TypeError, we just have been able to find out about the root cause. It was totally our fault, as we have been bitten by a custom routine monkeypatching the _make_request method of epo-ops-client [1]. Oh my! ;]

If you are curious, the only thing we changed to that method is that we didn't want to invoke raise_for_status().

# Let errors propagate. Don't croak on anything status >= 400.
#response.raise_for_status()

[1] https://github.com/ip-tools/ip-navigator/blob/6f35752e128f0c3138a306d8bce75199c0808cd6/patzilla/access/epo/ops/client.py#L105-L127

from python-epo-ops-client.

@amotl Feel free to file an enhancement issue and I can think about how best to allow that behavior to be toggle-able.

from python-epo-ops-client.

Thanks again!

from python-epo-ops-client.