Skip to content

Allow to specify per-line --install-option in requirements.txt #271

dgerzo opened this Issue Apr 26, 2011 · 53 comments
dgerzo commented Apr 26, 2011


This is a feature request, which would allow people to configure a per-line --install-option in requirements.txt for individual packages. This is needed for example when the installation of the package listed in requirements txt needs additional options, like in case of pylibmc, where I need to pass --install-option="--with-libmemcached=/usr/local" on FreeBSD systems.

Passing --install-option="--with-libmemcached=/usr/local" to the pip install -r requirements.txt is a no-go as that makes other packages fail with an unknown option. This is something that makes it difficult to use pip on automated deployments.




I have exactly the same issue on OpenBSD deployments. Glad I checked before I wrote what would have been a duplicate enhancement request.

daybarr commented Feb 6, 2012


I asked how to get around this limitation on StackOverflow:

As well as allowing manual addition of --install-option to the requirements.txt, it would be nice to maintain the round-trip ability by having pip install "remember" what install-options were used, so pip freeze can then write the --install-option back to the requirements.txt so it isn't lost when adding new packages or upgrading existing ones.


+1 I have exactly the same issue as daybarr above.

kwill commented Mar 1, 2012

+1 (although I wish github had an option to show support without having to add a +1 comment - is there a feature request for this somewhere that I could add a +1 comment to?)



This would be a great feature!!!

conrado commented Apr 12, 2012


carljm commented Apr 16, 2012

This is a reasonable feature, pull request welcome.

mitar commented Sep 22, 2012


nethi commented Nov 25, 2012


gthomas commented Nov 28, 2012


richg commented Jan 30, 2013



+1 (why oh why does GitHub not have a "plus one" feature)

Python Packaging Authority member
qwcode commented Jan 31, 2013

Hello, I'm a pip maintainer and agree this is important. 1.3 is due out very soon, so it won't be in that, but it's very much on the radar for 1.4.


Awesome, thanks. +1 also.



gvalkov commented Jan 31, 2013

I'll have a go at this, but lets agree on a format first. Maybe:

# All args after '--' will be consumed and used for '--install-options'
pylibmc -- --with-libmemcached=/usr/local
# ... or more explicitly
pylibmc --install-options --with-libmemcached=/usr/local

There is also the matter of how -r --requirement lines should be handled.Should --install-options be recursively applied to all requirements in the requirement file? What if the requirements file sets install options of its own?

-r url://to/requirements.txt -- --with-libmemcached=/usr/local

Maybe I should also add line continuations to the requirement file parser?

pylibc==1.0.1 --install-options \
              --with-libmemcached=/usr/local \
              --prefix=/home/gv/.local \
Python Packaging Authority member
qwcode commented Jan 31, 2013

I think this:

someproject==1.2 --install-option='...'

this allows us to support other options later if need be, w/o confusion.

-r url://to/requirements.txt -- --with-libmemcached=/usr/local

I'd say don't bother supporting that now. they can add the options into the lines in that file.

as for continuations, I'm open to that, but certainly not critical for this. I'd rather that be done separate.


Agree with everything @qwcode just said.

phu commented Feb 1, 2013

+1 Also running into this. Will be excellent when pip supports it; for now using a sort of workaround found in the comments here:

Python Packaging Authority member
qwcode commented Jul 14, 2013

understood, @gvalkov 's PR is in the 1.5 milestone (i.e. the next release)

guilload commented Oct 1, 2013


MiCHiLU commented Dec 26, 2013


I need --install-option=--static-deps option for installing lxml on Mac OS X 10.7

munhitsu commented Jan 2, 2014

+1 to make graphite users happier

Almad commented Jan 22, 2014

+1 for --egg with scons, otherwise uninstallable on heroku

yxw commented Feb 17, 2014



+1 causing problems installing to heroku without this.



granda commented Mar 25, 2014





+1 how is this still not fixed?

Python Packaging Authority member
qwcode commented Apr 22, 2014

@jaytaylor you got me. 1.5 is passed. didn't happen. btw, PR #790 was very close, but needs freshening at this point.


+1 still to this, and hoping someone takes it on soon.

RaviH commented Jun 6, 2014


Hi, do we know if there is any traction on this? Would this be available for Python 2.7 or would it only be available with later versions of Python?


been a couple of months so - 👍

darKoram commented Dec 1, 2014

Thread started april 2011!



@jbeezley jbeezley referenced this issue in girder/girder Dec 10, 2014

Improvements to #561

svisser commented Dec 14, 2014


juztin commented Feb 12, 2015



+1 I have this issue with python-ldap on freebsd.

ahammond commented Mar 4, 2015

+1 salt wants --salt-transport=raet

@vlotorev vlotorev referenced this issue in trezor/cython-hidapi Mar 6, 2015

make libusb optional on linux #9



Python Packaging Authority member
pfmoore commented Mar 11, 2015

There have been a lot of +1 comments on this, but until someone comes up with a PR, it's probably not going to go very far. Do any of the people commenting +1 have the time to work up a PR? Even a first draft that needs some help to polish would be good.

Python Packaging Authority member
pfmoore commented Mar 11, 2015

I agree with the comments @qwcode made on the design (don't bother allowing --install-options on -r lines, don't bother with the "anything after --" implicit approach, and leave line continuation to a separate PR). But otherwise this looks OK. I'm not 100% clear on where #790 stands on this matter, but assuming it takes those points into consideration, I'll review it once it's rebased.


#2537 seems to be progressing nicely.

johnyf commented Mar 29, 2015


gvalkov commented Mar 29, 2015

Hello everyone,

This functionality is now available in PR #2537 and is being considered for inclusion by the pip core team. They've been extremely helpful in reviewing and straightening out some of the loose ends.

Judging by the number of +1s in this thread, I imagine that a lot of you already have a specific use case in mind for this feature. If you happen to have the time, would you consider testing PR #2537?

Here's a quick way of getting the development version of pip + my feature branch:

$ git clone && cd pip
$ git fetch origin pull/2537/head:reqfileopts
$ git checkout reqfileopts
$ python -m pip <command> 

Please refer to the per-requirement overrides section for usage information. For example, to install salt with the --salt-transport=raet option from a requirements file:

$ cat > requirements-with-opts.txt <<EOF
salt --global-option="--salt-transport=raet"
$ python -m pip install -r requirements-with-opts.txt


conrado commented Mar 29, 2015

Georgi, did you reference the right PR? I think you meant #2537

gvalkov commented Mar 30, 2015

Certainly. Thank you for the catch, @conrado.

Python Packaging Authority member
qwcode commented Apr 12, 2015

closed via #2537

@qwcode qwcode closed this Apr 12, 2015
@doutriaux1 doutriaux1 referenced this issue in UV-CDAT/uvcdat Aug 14, 2015

SciPy fails to build on CentOS 6.6 #1192

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.