Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
changes in dependencies of dependencies of charm-tools have broken usage on trusty venvs #246
Comments
ryan-beisner
commented
Aug 18, 2016
|
Another way to look at this: setuptools If setuptools is forced to |
pushed a commit
to openstack/charm-cinder
that referenced
this issue
Aug 18, 2016
ryan-beisner
commented
Aug 19, 2016
|
FYI, the OSCI amulet test gate is currently blocked on this. While it's possible to work around this by modifying the test-requirements.txt in all of the OpenStack Charms, charm-tools is the right place to fix it IMHO (secretstorage<2.3.0). |
added a commit
to marcoceppi/charm-tools
that referenced
this issue
Aug 19, 2016
marcoceppi
referenced this issue
Aug 19, 2016
Merged
lock secretstorage because launchpadlib didn't fixes #246 #248
marcoceppi
closed this
in
#248
Aug 19, 2016
added a commit
that referenced
this issue
Aug 19, 2016
added a commit
that referenced
this issue
Aug 22, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ryan-beisner commentedAug 18, 2016
On Aug 16, this worked:
As of Aug 17, it doesn't:
This appears to be because secretstorage revved up on Aug 17:
https://pypi.python.org/pypi/SecretStorage
And the reqs lineage goes like so:
cryptography->secretstorage->keyring->launchpadlib->charm-toolsSetting an upper constraint for secretstorage seems to resolve the issue:
I am using: Trusty
Issue/Feature
I expect/expected the following
Charm-tools should successfully install in a virtualenv on Trusty.
What I got
Charm-tools has a dependency of a dependency that has changed, causing virtualenv charm-tools installations to break on Trusty.