Need a way in requirements.txt to force installing a package

I would love a way to be able to say, //in a requirements file//, “install this package even if it’s already installed somewhere.” This can be forced on the command line with the --upgrade flag, but you can’t do that in a req file.

The motivation here is that locally-installed packages in a virtualenv differ from globally-installed packages in at least one important respect: Executable scripts from global packages typically don’t work as expected in a virtualenv, because the shebang line points to the wrong python interpreter, thus effectively bypassing the virtualenv.

So, if I provide a requirements file that includes a line like foo==1.2.3, my expectation is that users will be able to run scripts provided by foo-1.2.3. In reality, those scripts will work for those users who don’t already have foo-1.2.3 installed, and likely NOT work for users who //do// already have it installed, and I’ll get confusing bug reports because the user probably doesn’t know that they already have it installed somewhere else, and neither do I.

Also, I can’t reliably provide automation scripts which use such python scripts, even if I call my own python interpreter instead of relying on the shebang line, because I don’t know if or where the script is installed, or even if there’s multiple versions installed - in which case which foo isn’t much help because I need the //right// one.

Right now the only workaround that I know of is to put “-e some-repo-url#egg=foo==1.2.3” in my requirements.txt. That forces installation. But this is kind of silly: I don’t care about the source, and the motivation is not at all obvious from reading the requirements file, and it adds more dependencies on development headers if foo needs to build C extensions.

For a concrete example where this bit me, see http://trac.pythonpaste.org/pythonpaste/ticket/458 . It also just bit me today while trying to support a user who was failing to install a Django app: http://groups.google.com/group/ebcode/tree/browse_frm/thread/a12098921d61cdc3/a020706cf3d1d162?rnum=11&_done=%2Fgroup%2Febcode%2Fbrowse_frm%2Fthread%2Fa12098921d61cdc3%3F#doc_2c9b22010a6e1457

---

• Bitbucket: https://bitbucket.org/ianb/pip/issue/218
• Originally Reported By:
• Originally Created At: 2011-02-18 21:59:33

[dstufft]

Closing this, I believe that this feature is a bit of an antipattern.

[mwarkentin]

+1 - we have a shared deployment library we use across ~14 applications. Each one has a deploy/ directory w/ a requirements.txt with a single line:

deploylib>=2.14.2,<3.0.0

We try to follow semver for this library, so we only need to update this file whenever there’s a breaking change and we can handle that on a per-app basis.

In general though, we’d like our devs to use the latest 2.X version of the lib - however we need them to remember to do pip install -U -r requirements.txt for this to happen.

We could also add a wrapper script, or a Makefile, or similar, but there’s no way of enforcing that they install packages that way instead of pip install -r requirements.txt which is pretty much muscle memory at this point.

Ideally we could just add --upgrade as the first line of the requirements file - initially thought we could do this when reading the docs, but noticed after trying that only specific pip options are supported within requirements.txt.

We may just remove the the requirements file altogether and provide a script / makefile to install via pip cli directly.