dynamodb-encryption-sdk tests failing

[alex]

https://travis-ci.org/pyca/cryptography/jobs/420582842

cc @mattsb42-aws

[mattsb42-aws]

Hmm, that is something completely different than I was expecting...looks like moto broke out from under us. :/

[mattsb42-aws]

Narrowing this down. My current prime suspect is the botocore urllib3 refactor that dropped yesterday. I suspect that it is not playing well with how moto uses it.

What I'm going to do is a) sort out what dependency broke us, and b) make a requirements freeze file before that change for use by your tests to avoid this type of thing happening again.

[alex]

Thanks for diving in

…

On Sat, Aug 25, 2018 at 5:33 PM Matt Bullock ***@***.***> wrote: Narrowing this down. My current prime suspect is the botocore urllib3 refactor that dropped yesterday. I suspect that it is not playing well with how moto uses it. What I'm going to do is a) sort out what dependency broke us, and b) make a requirements freeze file before that change for use by your tests to avoid this type of thing happening again. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBEmuW9amqG_1e1wURTEse20lRCIpks5uUcLDgaJpZM4WMhdD> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[mattsb42-aws]

Temporary fix merged, pinning tests on the earlier version of botocore. This should unblock your builds without any changes to the downstream test configuration.

The proper freeze ended up being more complicated than I thought it would be, thus this temporary fix. I'll be tackling that on Monday and submitting an update to the downstream test config once we have that figured out.

aws/aws-dynamodb-encryption-python#85

[alex]

@mattsb42-aws confirmed that we're green, thanks much!

[mattsb42-aws]

I've been wrestling with the best solution to this, and I've come to a few conclusions.

• This type of dependency freezing is something that would be beneficial for all of the downstream repos to support, and ideally it should not be too difficult for each repo to provide the necessary freeze file.
• Installing a naive freeze file for a downstream after installing the current dev state of pyca/cryptography does not do the intended thing because it uninstalls the installed dev version and instead installs the version mentioned in the freeze file.
• Creating a "freeze but without this dependency tree" is a much harder problem than anticipated given current pip tooling...especially when dependencies might take dependencies on the dependency that I wanted to remove.

For a simple to accomplish middle ground, if we were to simply split each downstream test into two stages: "install downstream repo and dependencies" and "run downstream tests", we could change the order of operations from:

1. Install pyca/cryptography branch head
2. Install downstream repo and dependencies
3. Run downstream tests

to:

1. Install downstream repo and dependencies
2. Install pyca/cryptography branch head
3. Run downstream tests

This would let the pyca/cryptography install overwrite any package versions that the downstream repo installed with any newer requirements, which I would imagine is closer to what they are intended to test anyway.

This does have the drawback of leaving open the potential for orphaned dependencies to stick around and possibly mask some errors, but it's the simplest balance I can think of that does not involve adding new functionality to pip.

Thoughts?

I have what I have in mind prototyped here[1] (with a crafted branch name to get Travis to run the tests).

[1] mattsb42-aws@918298b

[mattsb42-aws]

#4418 created with proposed general fix