Add --no-binary flag to pip for packages without wheels

[bmw]

certbot-auto/letsencrypt-auto require specific versions of all our Python dependencies and verifies the hashes of all downloaded packages. Doing this increases both the security and the stability of the scripts. To do this, however, we need to include a hash of each installation mechanism uploaded to PyPI (sdists, wheels, etc.).

Over the weekend, pycparsing uploaded a new installation mechanism to PyPI. Previously, they only had a sdist available, but over the weekend they uploaded a wheel. When using pip to install packages from PyPI, it prefers wheels over sdists. The result of all of this is when using certbot-auto to install pycparsing, pip would download the wheel, check it against the hash(es) we have for pycparsing, and exit with a message about an invalid hash.

pycparsing has since removed this wheel due to other problems with it resolving our issue. In general, I think it is uncommon to add a distribution mechanism for an already released version of a package. In my experience, things like this are usually added when a new version of the package is released.

With that said, there's nothing stopping us from having this problem in the future. To try and help mitigate this problem, perhaps we should add --no-binary to our usage of pip for packages that currently do not have a wheel available. Using this approach, if a wheel is added to one of our dependencies without bumping the package version, certbot-auto users are unaffected.

[bmw]

@erikrose, I'd like your opinion on this. Do you think this is something we should spend time doing? Do you have a better solution? How common is it for a package to add new distribution mechanisms without bumping the version number?

[pde]

Is there a chance that pycparsing is going to fix their wheel and re-upload it in the near future?

[bmw]

Good question.

[erikrose]

How common is it for a package to add new distribution mechanisms without bumping the version number?

I've never seen that happen before, but adding --no-binary is not a bad idea.

[bmw]

pycparser maintainer's answer to @pde's question.

[reubano]

I just ran into this issue and had to add --no-binary to enum34, zope.interface, and mock as well.

[bmw]

@reubano, really? What OS are you on? What version of Python are you using?

EDIT: What were the errors without --no-binary?

[reubano]

Mac OSX 10.9.5
Python 3.5.2
pip 8.0.3
certbot-auto 0.9.3

the errors I got were about mismatched hashes, basically the same errors I got for pycparsing.

[laike9m]

pip 8.0.3 also brought this error.

[individual8]

I followed the recommendations in this issue and still have no solution. Any ideas?

Here's the output of letsencrypt-auto renew: letsencrypt_fail.txt

[erikrose]

@individual8 It looks like you have a separate problem, some kind of C compilation error in your openssl headers. I'd try upgrading the headers and see if that helps. (Of course, if you can use a binary, pre-built version of cryptography, you won't have to do the build at all.)

[individual8]

@erikrose Thx for pointing into the direction.

I'm still perplex though, why is this issue? And why has everyone one of their own?

[individual8]

@erikrose Upgraded...

pip install cryptography
Requirement already satisfied (use --upgrade to upgrade): cryptography in /usr/lib/python2.7/dist-packages
root@j290147:/usr/local/bin# pip install cryptography --upgrade
Collecting cryptography
  Downloading cryptography-1.6.tar.gz (410kB)
    100% |████████████████████████████████| 419kB 1.5MB/s
Requirement already up-to-date: idna>=2.0 in /usr/lib/python2.7/dist-packages (from cryptography)
Requirement already up-to-date: pyasn1>=0.1.8 in /usr/lib/python2.7/dist-packages (from cryptography)
Requirement already up-to-date: six>=1.4.1 in /usr/lib/python2.7/dist-packages (from cryptography)
Collecting setuptools>=11.3 (from cryptography)
  Using cached setuptools-29.0.1-py2.py3-none-any.whl
Requirement already up-to-date: enum34 in /usr/lib/python2.7/dist-packages (from cryptography)
Requirement already up-to-date: ipaddress in /usr/lib/python2.7/dist-packages (from cryptography)
Collecting cffi>=1.4.1 (from cryptography)
  Downloading cffi-1.9.1-cp27-cp27mu-manylinux1_x86_64.whl (387kB)
    100% |████████████████████████████████| 389kB 1.8MB/s
Collecting pycparser (from cffi>=1.4.1->cryptography)
  Downloading pycparser-2.17.tar.gz (231kB)
    100% |████████████████████████████████| 235kB 3.0MB/s
Building wheels for collected packages: cryptography, pycparser
  Running setup.py bdist_wheel for cryptography ... done
  Stored in directory: /root/.cache/pip/wheels/c1/b0/c1/00756c24fd3ad4bba815bacbbbaa819718ecb63039e379ea6b
  Running setup.py bdist_wheel for pycparser ... done
  Stored in directory: /root/.cache/pip/wheels/a8/0b/41/dc95621f9d3a0da7bc191b8a71f0e8182ffd3cc5f33ac55005
Successfully built cryptography pycparser
Installing collected packages: setuptools, pycparser, cffi, cryptography
  Found existing installation: setuptools 28.7.1
    Not uninstalling setuptools at /usr/lib/python2.7/dist-packages, outside environment /usr
  Found existing installation: cryptography 1.5.3
    Not uninstalling cryptography at /usr/lib/python2.7/dist-packages, outside environment /usr
Successfully installed cffi-1.9.1 cryptography-1.6 pycparser-2.17 setuptools-29.0.1

Still not working, do I need to update the letsencrypt-auto script for sth. to take effect?

[individual8]

After adding a swap file (what some suggested) on my 2GB VM, still no luck.

Instead I tried to install certbot via apt-get install python-certbot-apache. Installed w/o problems. Ran certbot renew and it seems it did the job.

Glad, still without words why though.

[bmw]

@individual8, the problem you are having is different from the one described in this issue. In general, OS packages should be preferred over certbot-auto as that was built to be a temporary workaround for older distros without Certbot packages. The problem you are having is #3732 which was fixed in #3773 which will be included in our next release.

[individual8]

Thx @bmw. Are you saying I'm fine or are you not?

I was using letsencrypt, installed manually as far as I recall, now I use certbot, installed as described above.

[bmw]

Using certbot as installed through apt should work just fine.

[stcalica]

still hasn't worked for me and installing with apt isn't working.

[pdamodaran]

working on this

[bmw]

We did a simple version of this in #6023. I think it's OK if we don't maintain these --no-binary flags in the long term, but for now it should make certbot-auto a little more resilient to these kinds of problems in the future.