Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pin jmespatch dependency version #656

Closed
BrianEWhipple opened this issue Sep 23, 2015 · 4 comments
Closed

Pin jmespatch dependency version #656

BrianEWhipple opened this issue Sep 23, 2015 · 4 comments
Labels
bug

Comments

@BrianEWhipple
Copy link

@BrianEWhipple BrianEWhipple commented Sep 23, 2015

Can this library pin its jmespath dependency to a specific version? Currently, it depends on the development branch of the jmespath GitHub repo - which is not stable nor deterministic.

Currently, this project's setup.py requires version 0.7.1 but the upstream GitHub repo/branch does not deliver that version - so this project's dependency graph is disconnected.

This can result in runtime errors for downstream consumers - like my organization did today.

@jamesls
Copy link
Member

@jamesls jamesls commented Sep 23, 2015

Could you elaborate on what runtime errors you encountered? I'd like to understand how this is breaking downstream consumers before fixing. The only place we reference the dev branch of jmespath is in the requirements.txt file, which we only use for running our tests. pip install botocore will always pull in the locked version of jmespath from the setup.py.

@jamesls jamesls added the response-requested label Sep 23, 2015
@BrianEWhipple
Copy link
Author

@BrianEWhipple BrianEWhipple commented Sep 23, 2015

Today we started getting runtime errors:

raise DistributionNotFound(req, requirers)

pkg_resources.DistributionNotFound: The 'jmespath==0.7.1' distribution was not found and is required by botocore

Version 0.8.0 of jmespath was being installed into our site-packages instead of 0.7.1. I'm not sure exactly how pip manages transitive dependencies - I'll poke into that more and try to find the root problem.

I should have also mentioned that we pin our version of botocore to 1.1.6.

@jamesls
Copy link
Member

@jamesls jamesls commented Sep 24, 2015

Ok. I think the problem is that because botocore has a dependency that's too strict, if something else pulls in a newer jmespath then you'll run into this problem. Pip doesn't seem to handle this well, for example, in a fresh virtualenv, if I install botocore, then boto3 I get:

$ pip install botocore boto3
Successfully installed boto3-1.1.3 botocore-1.2.4 docutils-0.12 futures-2.2.0 jmespath-0.7.1 python-dateutil-2.4.2 six-1.9.0
$ python -c "import jmespath; print jmespath.__version__"
0.7.1

When I reverse the order, I get:

$ pip install boto3 botocore
Successfully installed boto3-1.1.3 botocore-1.2.4 docutils-0.12 futures-2.2.0 jmespath-0.8.0 python-dateutil-2.4.2 six-1.9.0
$ python -c "import jmespath; print jmespath.__version__"
0.8.0

What I would propose if relaxing the version constraint here. botocore doesn't actually need thing that's only in v0.7.1 so if change this to be the same as boto3, that is: jmespath>=0.6.2,<1.0.0 this should fix the issue.

@jamesls
Copy link
Member

@jamesls jamesls commented Sep 24, 2015

Also reported in: boto/boto3#270

jamesls added a commit to jamesls/botocore that referenced this issue Sep 24, 2015
jamesls added a commit to jamesls/boto3 that referenced this issue Sep 24, 2015
This is strictly needed, but we should match
the same version range that botocore uses.

Related: boto/botocore#656

Fixes boto#270.
@jamesls jamesls added bug and removed response-requested labels Sep 24, 2015
jamesls added a commit to boto/boto3 that referenced this issue Sep 24, 2015
This is strictly needed, but we should match
the same version range that botocore uses.

Related: boto/botocore#656

Fixes #270.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug
Projects
None yet
Development

No branches or pull requests

2 participants