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

pyasn1 is a dependency that doesn't get upgraded #5

Open
breu opened this issue Feb 8, 2016 · 8 comments
Open

pyasn1 is a dependency that doesn't get upgraded #5

breu opened this issue Feb 8, 2016 · 8 comments

Comments

@breu
Copy link

breu commented Feb 8, 2016

On an ubuntu 12.04 precise machine, upgrading ndg-httpsclient when python-asn1 is installed will break with

  File "/usr/local/lib/python2.7/dist-packages/ndg/httpsclient/subj_alt_name.py", line 105, in AnotherName
    namedtype.NamedType('value', univ.Any().subtype(
AttributeError: 'module' object has no attribute 'Any'

Upgrading pyasn1 before upgrading ndg-httpsclient results in a working system. I think pyasn1 should be a dep here with a minimum version number (just not sure what it is)

@philipkershaw
Copy link
Member

When I first added pyasn1 my feeling was that it was better as an optional package: not everyone would want full subject alt name support. It seems to me with the above, I would need to make it a compulsory package. However it looks like you have a workaround by ensuring pyasn1 is installed first. It's not ideal but means pyasn1 stays as an optional package. Happy to be convinced otherwise if you feel it should be compulsory.

@philipkershaw
Copy link
Member

I'd be interested to hear if pyasn1 as a compulsory package would make life easier in general. Otherwise I will leave as is and close this ticket.

@jayvdb
Copy link
Contributor

jayvdb commented Jun 7, 2016

So Ubuntu precise has v0.0.11a by default, and
univ.Any appeared in v0.0.13a.

It can remain an optional dependency, by using

extras_require={'subjectAltName_support': 'pyasn1>=0.0.13'},

@jayvdb
Copy link
Contributor

jayvdb commented Jun 7, 2016

Hmm, this might be part of the problem.

https://travis-ci.org/jayvdb/ndg_httpsclient/jobs/135839291
https://travis-ci.org/jayvdb/requests/jobs/135838126#L661

I suspect the problem is that pip on Ubuntu is using ndg_httpsclient, and the current ndg_httpsclient conflicts with the old pyasn1, so pip breaks during installation.

Anyway, valid versions of pyasn1 to choose from are : 0.0.9a0, 0.0.10a0, 0.0.11a0, 0.0.12a0, 0.0.13a0, 0.0.13b0, 0.0.13, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9

And I have found a semi-reasonable workaround to the problem.

However 0.0.13 doesnt install on Python 3, so I think the minimum should be at least 0.1.1.

However I see that cryptography requires pyasn1>=0.1.8 , so it is likely most people will be using that soon.

@bengotow
Copy link

Would love to see this merged! The pyasn1 issue is causing issues for us downstream nylas/sync-engine#385

@philipkershaw
Copy link
Member

I've set a minimum version dependency for pyasn1>=0.0.1 as in John's fork (thanks). Is this sufficient for your needs?

If so I'll cut the new release and put in PyPI.

Trying a pip install on Python 2.7 with dist tarball generated from dev branch, cryptography appears to enforce a minimum version of 0.1.8 for pyasn1. See below . . .

Collecting ndg-httpsclient
Collecting PyOpenSSL (from ndg-httpsclient)
  Downloading pyOpenSSL-16.1.0-py2.py3-none-any.whl (43kB)
    100% |████████████████████████████████| 51kB 4.9MB/s 
Collecting six>=1.5.2 (from PyOpenSSL->ndg-httpsclient)
  Using cached six-1.10.0-py2.py3-none-any.whl
Collecting cryptography>=1.3.4 (from PyOpenSSL->ndg-httpsclient)
  Downloading cryptography-1.5.tar.gz (400kB)
    100% |████████████████████████████████| 409kB 2.8MB/s 
Collecting idna>=2.0 (from cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
  Using cached idna-2.1-py2.py3-none-any.whl
Collecting pyasn1>=0.1.8 (from cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
  Using cached pyasn1-0.1.9-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): setuptools>=11.3 in /home/pjkersha/virtualenvs/ndg-https-client-test-install-py27/lib/python2.7/site-packages (from cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
Collecting enum34 (from cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
  Using cached enum34-1.1.6-py2-none-any.whl
Collecting ipaddress (from cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
  Using cached ipaddress-1.0.16-py27-none-any.whl
Collecting cffi>=1.4.1 (from cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
  Downloading cffi-1.7.0-cp27-cp27mu-manylinux1_x86_64.whl (383kB)
    100% |████████████████████████████████| 389kB 2.6MB/s 
Collecting pycparser (from cffi>=1.4.1->cryptography>=1.3.4->PyOpenSSL->ndg-httpsclient)
Building wheels for collected packages: ndg-httpsclient, cryptography
  Running setup.py bdist_wheel for ndg-httpsclient ... done
  Stored in directory: /home/pjkersha/.cache/pip/wheels/a9/20/85/11b14ee4749b21f4a8f54b7d032994f4109a3a29a59da5bb49
  Running setup.py bdist_wheel for cryptography ... done
  Stored in directory: /home/pjkersha/.cache/pip/wheels/d4/98/43/a428a8aed7285f934d18efd787647455d7ef9a9dda81f22839
Successfully built ndg-httpsclient cryptography
Installing collected packages: six, idna, pyasn1, enum34, ipaddress, pycparser, cffi, cryptography, PyOpenSSL, ndg-httpsclient
Successfully installed PyOpenSSL-16.1.0 cffi-1.7.0 cryptography-1.5 enum34-1.1.6 idna-2.1 ipaddress-1.0.16 ndg-httpsclient-0.4.3 pyasn1-0.1.9 pycparser-2.14 six-1.10.0

@jayvdb
Copy link
Contributor

jayvdb commented Sep 1, 2016

I am rebasing my branch now.
I ran into unexpected difficulties with pypa/pip#3945

@philipkershaw
Copy link
Member

I've updated devel making pyasn1>=0.1.1 a mandatory dependency. This is simpler given PyOpenSSL dependency cryptography requires it anyway. Unless I hear otherwise I'll put the new release into PyPI on Monday.

jbarno pushed a commit to NCI-GDC/cdisutils that referenced this issue Oct 17, 2017
May solve the crypto error during pip install on a tungstend deploy (link)[cedadev/ndg_httpsclient#5 (comment)]
jbarno pushed a commit to NCI-GDC/cdisutils that referenced this issue Nov 2, 2017
May solve the crypto error during pip install on a tungstend deploy (link)[cedadev/ndg_httpsclient#5 (comment)]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants