--no-use-wheel argument fails requirement installation

[i11]

Hi!

I have an issue with using python::virtualenv and specified requirements.
Here is what I have:

RHEL 6.4
Python 2.6.6
Pip 6.0.8
Virtualenv 1.10.1

resource definition:

  ::python::virtualenv { '/opt/virtualenv/head':
    ensure       => present,
    requirements => '/opt/virtualenv/initial_build_head/requirements.txt',
    systempkgs   => false,
    owner        => $user,
    group        => $user,
    timeout      => 0,
    require      => Vcsrepo['/opt/virtualenv/initial_build_head']
  }

/opt/virtualenv/initial_build_head/requirements.txt:

BeautifulSoup==3.2.1
Fabric==1.10.1
psutil==1.1.2
http://cdn.mysql.com/Downloads/Connector-Python/mysql-connector-python-1.0.12.zip#md5=6c379e1108c8465ebfe3d2699688300a
simplejson==2.0.9
jira==0.35

Command equivalent to Exec[["python_requirements_initial_install_${requirements}_${venv_dir}"]](from virtualenv.pp) results:

# /opt/virtualenv/head/bin/pip --log /opt/virtualenv/head/pip.log install --no-use-wheel -r /opt/virtualenv/initial_build_head/requirements.txt
Collecting http://cdn.mysql.com/Downloads/Connector-Python/mysql-connector-python-1.0.12.zip#md5=6c379e1108c8465ebfe3d2699688300a (from -r /opt/virtualenv/initial_build_head/requirements.txt (line 5))
  Downloading http://cdn.mysql.com/Downloads/Connector-Python/mysql-connector-python-1.0.12.zip (313kB)
    100% |################################| 315kB 1.3MB/s 
    /tmp/pip-pnoopU-build/setup.py:12: DeprecationWarning: Parameters to load are deprecated.  Call .resolve and .require separately.
      #
Collecting BeautifulSoup==3.2.1 (from -r /opt/virtualenv/initial_build_head/requirements.txt (line 2))
  Using cached BeautifulSoup-3.2.1.tar.gz
    /tmp/pip-build-IMawNl/BeautifulSoup/setup.py:12: DeprecationWarning: Parameters to load are deprecated.  Call .resolve and .require separately.
Collecting Fabric==1.10.1 (from -r /opt/virtualenv/initial_build_head/requirements.txt (line 3))
  Using cached Fabric-1.10.1.tar.gz
    /tmp/pip-build-IMawNl/Fabric/setup.py:12: DeprecationWarning: Parameters to load are deprecated.  Call .resolve and .require separately.
      with open('README.rst') as f:
Collecting psutil==1.1.2 (from -r /opt/virtualenv/initial_build_head/requirements.txt (line 4))
  Using cached psutil-1.1.2.tar.gz
    /tmp/pip-build-IMawNl/psutil/setup.py:12: DeprecationWarning: Parameters to load are deprecated.  Call .resolve and .require separately.
      try:
Collecting simplejson==2.0.9 (from -r /opt/virtualenv/initial_build_head/requirements.txt (line 6))
  Using cached simplejson-2.0.9.tar.gz
    /tmp/pip-build-IMawNl/simplejson/setup.py:53: DeprecationWarning: Features are deprecated and will be removed in a future version. See http://bitbucket.org/pypa/setuptools/65.
      Extension("simplejson._speedups", ["simplejson/_speedups.c"]),
    /usr/lib64/python2.6/distutils/core.py:113: DeprecationWarning: Features are deprecated and will be removed in a future version. See http://bitbucket.org/pypa/setuptools/65.
      _setup_distribution = dist = klass(attrs)
    /tmp/pip-build-IMawNl/simplejson/setup.py:12: DeprecationWarning: Parameters to load are deprecated.  Call .resolve and .require separately.
      # If a non-local ez_setup is already imported, it won't be able to
Collecting jira==0.35 (from -r /opt/virtualenv/initial_build_head/requirements.txt (line 7))
  Using cached jira-0.35.tar.gz
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-IMawNl/jira/setup.py", line 10, in <module>
        from jira import __version__
      File "jira/__init__.py", line 5, in <module>
        from .config import get_jira
      File "jira/config.py", line 15, in <module>
        from six.moves import configparser
    ImportError: No module named six.moves
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

      File "<string>", line 20, in <module>

      File "/tmp/pip-build-IMawNl/jira/setup.py", line 10, in <module>

        from jira import __version__

      File "jira/__init__.py", line 5, in <module>

        from .config import get_jira

      File "jira/config.py", line 15, in <module>

        from six.moves import configparser

    ImportError: No module named six.moves

    ----------------------------------------
    Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-IMawNl/jira

After removing --no-use-wheel argument the result was successful.

Any ideas?

Thanks!

[cpatrick]

I'm also seeing this issue.

[ghoneycutt]

Should we be using --no-binary :all: for Python < 2.7 instead of --no-use-wheel?

@i11 @cpatrick can you see if doing this manually works for you?

pypa/pip#3191
pypa/pip#1891

[zymergen-jonas]

I stumbled upon this issue when encountering a similar problem. I believe this option is used under incorrect assumptions, at least in the context of recent Python versions. Here is the related code comment:

  # We need to jump through hoops to make sure we issue the correct pip command
  # depending on wheel support and versions.
  #
  # Pip does not support wheels prior to version 1.4.0
  # Pip wheels require setuptools/distribute > 0.8
  # Python 2.6 and older does not support setuptools/distribute > 0.8
  # Pip >= 1.5 tries to use wheels by default, even if wheel package is not
  # installed, in this case the --no-use-wheel flag needs to be passed
  # Versions prior to 1.5 don't support the --no-use-wheel flag
  #
  # To check for this we test for wheel parameter using help and then using
  # show, this makes sure we only use wheels if they are supported and
  # installed

The code does indeed check for the presence of the wheel package and if not found, adds the --no-use-wheel flag. This throws a deprecation warning with the hint that it should be --no-use-binary which is documented here.

Deprecation warnings aside, the premise of this strategy seems wrong: The wheel package is only required for building wheels, not for installing them. This is true at least for pip versions 9 and 10. But I also don't remember an earlier version that would have downloaded wheels and then discover that it cannot install them. Therefore, my understanding is that removing this option is always the right solution, and the pip docs (linked above) all but confirm this with the note that

[...] some packages are tricky to compile and may fail to install when this option is used on them.

[pillarsdotnet]

This was fixed in #483

[bastelfreak]

Hi @i11. I'm going to close this PR. Please reopen it if it isn't fixed for you in the master branch.