search

soroco / pyce

Encrypted Python Execution
Apache License 2.0
198 stars 26 forks source link

Version pinning cryptography causes dependency conflicts #12

Closed jorge-gasca closed 5 years ago

jorge-gasca commented 6 years ago

Example conflict when installing pyce 1.0.0 and paramiko through pipenv: Could not find a version that matches cryptography==2.1.4,>=2.2.

Could we change the strict version to >=2.1.4, <3.0.0?

theonewolf commented 6 years ago

We can if we get CI in place testing all versions of cryptography with pyce that are within your range scope.

We'd want to create a virtualenv I think for each version, test it with the test script (for now, no unit tests yet), and only set those versions after testing completes.

I'd be happy to do that once the CI is in place.

jorge-gasca commented 6 years ago

I was assuming that they followed semantic versioning, but according to the cryptography docs, 2.2 could break compatibility. We should set up some sort of CI then. @aaronsewall

theonewolf commented 6 years ago

@jorge-gasca semantic versioning does not say anything about the outcome of integration tests. It claims backwards compatibility to a certain API. Occasionally, even that claim is violated by developers for various reasons. And a version number is not enough to communicate such subtleties downstream.

In an ideal world, yes, it would pass integration tests. In reality, you can not say anything principled about a derived product when an upstream version changes even a single bit within their product.

If we consider computer programs as proofs, which they are as mathematical objects (https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence), you've just changed the proof without properly type checking it.

I prefer sound(er) engineering. We aren't quite as thorough as a proof, but at least it passes the tests we'd care about if we get CI in place.

So, even for semantically versioned libraries, I would only trust versions that we have CI for, and passing CI.

I think I'd be happy for now if the demo.sh script continued working across various versions of the cryptography library.

aaronsewall commented 6 years ago

I hand tested different versions with both the 1.0.0 release (3.6 compatible) and the current master branch (3.7 compatible).

1.0.0 supports all cryptography>=1.7.1 master supports cryptography>=2.2.2

Really this came down more to what cryptography itself supports for python versions. Their API surrounding the functions we use for pyce hasn't apparently changed since Dec 13, 2016.

Ideally master would still be compatible with 3.6, or at least include logic to automatically switch functions that aren't 3.6 compatible.

theonewolf commented 5 years ago

I agree on the ideal for supporting 3.6 and 3.7 at the same time, but unless we have better CI or more resources we can't right now.

For the time being, closing as WONTFIX.