Pip: --install-option (in the cli) get's passed to deps being installed

[s0undt3ch]

$ pip install --install-option='--salt-root=/foo' salt
Downloading/unpacking salt
  Downloading salt-2014.1.5.tar.gz (2.8MB): 2.8MB downloaded
  Running setup.py (path:/tmp/ve-test/build/salt/setup.py) egg_info for package salt
    2014.1.5

    package init file 'salt/templates/__init__.py' not found (or not a regular file)
Downloading/unpacking Jinja2 (from salt)
  Downloading Jinja2-2.7.3.tar.gz (378kB): 378kB downloaded
  Running setup.py (path:/tmp/ve-test/build/Jinja2/setup.py) egg_info for package Jinja2

    warning: no files found matching '*' under directory 'custom_fixers'
    warning: no previously-included files matching '*' found under directory 'docs/_build'
    warning: no previously-included files matching '*.pyc' found under directory 'jinja2'
    warning: no previously-included files matching '*.pyc' found under directory 'docs'
    warning: no previously-included files matching '*.pyo' found under directory 'jinja2'
    warning: no previously-included files matching '*.pyo' found under directory 'docs'
Downloading/unpacking M2Crypto (from salt)
  Downloading M2Crypto-0.22.3.tar.gz (74kB): 74kB downloaded
  Running setup.py (path:/tmp/ve-test/build/M2Crypto/setup.py) egg_info for package M2Crypto

Downloading/unpacking msgpack-python (from salt)
  Downloading msgpack-python-0.4.2.tar.gz (114kB): 114kB downloaded
  Running setup.py (path:/tmp/ve-test/build/msgpack-python/setup.py) egg_info for package msgpack-python

Downloading/unpacking pycrypto (from salt)
  Downloading pycrypto-2.6.1.tar.gz (446kB): 446kB downloaded
  Running setup.py (path:/tmp/ve-test/build/pycrypto/setup.py) egg_info for package pycrypto

Downloading/unpacking PyYAML (from salt)
  Downloading PyYAML-3.11.tar.gz (248kB): 248kB downloaded
  Running setup.py (path:/tmp/ve-test/build/PyYAML/setup.py) egg_info for package PyYAML

Downloading/unpacking pyzmq>=2.2.0 (from salt)
  Downloading pyzmq-14.3.1.tar.gz (982kB): 982kB downloaded
  Running setup.py (path:/tmp/ve-test/build/pyzmq/setup.py) egg_info for package pyzmq

    no previously-included directories found matching 'docs/build'
    no previously-included directories found matching 'docs/gh-pages'
    warning: no previously-included files found matching 'bundled/zeromq/src/Makefile*'
    warning: no previously-included files found matching 'bundled/zeromq/src/platform.hpp'
    warning: no previously-included files found matching 'setup.cfg'
    warning: no previously-included files found matching 'zmq/libzmq*'
    warning: no previously-included files matching '__pycache__/*' found anywhere in distribution
    warning: no previously-included files matching '.deps/*' found anywhere in distribution
    warning: no previously-included files matching '*.so' found anywhere in distribution
    warning: no previously-included files matching '*.pyd' found anywhere in distribution
    warning: no previously-included files matching '.git*' found anywhere in distribution
    warning: no previously-included files matching '.DS_Store' found anywhere in distribution
    warning: no previously-included files matching '.mailmap' found anywhere in distribution
    warning: no previously-included files matching 'Makefile.am' found anywhere in distribution
    warning: no previously-included files matching 'Makefile.in' found anywhere in distribution
Downloading/unpacking MarkupSafe (from salt)
  Downloading MarkupSafe-0.23.tar.gz
  Running setup.py (path:/tmp/ve-test/build/MarkupSafe/setup.py) egg_info for package MarkupSafe

Downloading/unpacking apache-libcloud (from salt)
  Downloading apache_libcloud-0.14.1-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded
Installing collected packages: salt, Jinja2, M2Crypto, msgpack-python, pycrypto, PyYAML, pyzmq, MarkupSafe, apache-libcloud
  Running setup.py install for salt
    2014.1.5
    package init file 'salt/templates/__init__.py' not found (or not a regular file)

    Installing salt-run script to /tmp/ve-test/bin
    Installing salt-minion script to /tmp/ve-test/bin
    Installing salt script to /tmp/ve-test/bin
    Installing salt-key script to /tmp/ve-test/bin
    Installing salt-call script to /tmp/ve-test/bin
    Installing salt-cp script to /tmp/ve-test/bin
    Installing salt-syndic script to /tmp/ve-test/bin
    Installing salt-ssh script to /tmp/ve-test/bin
    Installing salt-master script to /tmp/ve-test/bin
    Installing salt-cloud script to /tmp/ve-test/bin
  Running setup.py install for Jinja2
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
       or: -c --help [cmd1 cmd2 ...]
       or: -c --help-commands
       or: -c cmd --help

    error: option --salt-root not recognized
    Complete output from command /tmp/ve-test/bin/python2 -c "import setuptools, tokenize;__file__='/tmp/ve-test/build/Jinja2/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-gFIT34-record/install-record.txt --single-version-externally-managed --compile --install-headers /tmp/ve-test/include/site/python2.7 --salt-root=/foo:
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]

   or: -c --help [cmd1 cmd2 ...]

   or: -c --help-commands

   or: -c cmd --help



error: option --salt-root not recognized

----------------------------------------
Cleaning up...
Command /tmp/ve-test/bin/python2 -c "import setuptools, tokenize;__file__='/tmp/ve-test/build/Jinja2/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-gFIT34-record/install-record.txt --single-version-externally-managed --compile --install-headers /tmp/ve-test/include/site/python2.7 --salt-root=/foo failed with error code 1 in /tmp/ve-test/build/Jinja2
Storing debug log for failure in /home/vampas/.pip/pip.log

[holbech]

I'm affected by this one as well. For now I'm resorting to ugly hacks using environment variables instead.

[johnyf]

Same here. What is the point of providing --install-option, if it will get passed to the dependencies and cause a failure ?
This makes it practically impossible to use --install-option for any package that has dependencies.

[johnyf]

It would be expected that --global-options are supposed to be passed to dependencies, but not --install-options. This is not the case in RequirementSet.install though.

[qwcode]

starting with pip v7, pip supports using --install-option per line (i.e. per requirement) in a requirements file, which provides a solution for your need. in this use case, --install-option is not passed down to dependencies.

so like this

`pip install -r requirements.txt'

where requirements.txt contains

salt --install-option='--salt-root-dir=/foo'

using --install-option directly in the cli currently makes it global to the whole execution of pip, i.e. all top-level requirements and subdependencies.

I guess it could be changed to only apply to top-level requirements, but I'm not sure given the new support in requirements files.

i.e. supposing pip install --install-option='blah' pkg1 pkg2 pkg3, it would only apply to pkg1, pkg2, and pkg3, but not any dependencies.

[johnyf]

Thanks a lot! I was aware of the newly introduced --install-option in requirement files, but after observing the command-line behavior, I assumed that it will be the same. This solves the main issue I had, which was to automate fetching a C library for compiling an extension of a dependency.

I cannot make this the default behavior (as it fetches a tarball external to PyPI, and also, the user may already have the library installed somewhere, and so want to set CFLAGS, LDFLAGS instead). So it has to be an extra option to setup.py. The only way to selectively pass an option to a dependency is through a requirements file, so no problem there.

The only other use case is when someone installs directly the package, and cannot pass this as a command line option via pip. Since this is a direct install, it wouldn't be very different to unpack the package and run setup.py directly, or to clone and do the same thing (after all, this seems to be the only way for passing compiler directives as environment variables).

A temporary workaround for this use case may be:

pip install foo
pip install --no-deps --force-reinstall --upgrade --install-option="--do-some-magic" foo

This should first install dependencies w/o passing any flags, then re-install the package only, passing --do-some-magic. (I added --upgrade, because it didn't work w/o it.)

[t-neumann]

Is the a resolution for that issue available yet?

This temporary workaround of first installing the package with dependencies and then re-installing the package with --install-option is not working for me:

Additional software is installed during the installation of the package and the --install-option could skip this step. But there's no use for this flag to simply install everything including the software first, just to then uninstall it again.

[pradyunsg]

I'm pretty sure that the only reason this has not been fixed is because no one has come around to fixing this.

[fpelliccioni]

Same problem here.
Does anyone know how to capture a --global-option from my setup.py?

[vcolano]

Going on 4 years this has been open and still no fix... any updates on when we might see some progress?

[ollamh]

Any updates on this one? For those who can't use requirements file this is crucial option to have.

[chrahunt]

Assuming we want to NOT pass options to dependencies by default (and possibly remove the ability entirely), one possible approach would be:

1. Introduce a flag --pass-options-to-deps that makes pip behave the way it currently does. --no-pass-options-to-deps makes pip not pass options to dependencies.
2. By default assume that we should pass options to dependencies, but if no explicit option was passed then print a deprecation warning stating that the behavior is changing in (if implemented right now) 20.2.
3. In 20.2, change the default and remove the deprecation warning

If we want to remove the options getting passed to all dependencies behavior then the deprecation warning should also be traced if --pass-options-to-deps is used.

One reason we may want to remove the behavior entirely is to transition fully over to config settings (#5771), which we could incorporate this kind of configuration into.

[chrahunt]

Removing bug label since this was almost certainly done intentionally initially for location-related options (like those deprecated in #7309).