{"id":793,"date":"2016-06-09T03:54:19","date_gmt":"2016-06-09T03:54:19","guid":{"rendered":"https:\/\/www.crccheck.com\/blog\/?p=793"},"modified":"2016-06-11T03:09:29","modified_gmt":"2016-06-11T03:09:29","slug":"requirements-txt","status":"publish","type":"post","link":"https:\/\/www.crccheck.com\/blog\/requirements-txt\/","title":{"rendered":"requirements.txt==2.0"},"content":{"rendered":"

There is a war going on. A war between those that say Python requirements should be explicit and those that say requirements should be implicit. Before I continue, I’m going to be talking about requirements.txt<\/code>, not setup.py<\/code>. The difference between explicit and implicit requirements comes down to whether the line says Django==1.9.7<\/code> or Django<\/code>, respectively. Going deeper, you could also say that adding dependencies of dependencies is explicit, and you could loosely pin like Django<1.10.<\/code><\/p>\n

The advantage of explicit requirements is you get a repeatable environment. Especially if you’re also specifying dependencies of dependencies. The advantages of implicit requirements are readability and automatic security upgrades.<\/p>\n

Here at TabbedOut, we’ve developed a technique that works very well I’d like to share: Use pip-tools<\/code> to manage your requirements. You get the best of both worlds, at the expense of some extra boilerplate. Here’s how we do it:<\/p>\n

    \n
  1. Be in a virtualenv<\/li>\n
  2. Use our Makefile boilerplate (see below)<\/li>\n
  3. pip install pip-tools<\/code><\/li>\n
  4. Write a “sloppy” requirements.txt using implicit requirements, but name it requirements.in<\/code><\/li>\n
  5. Run make requirements.txt<\/code><\/li>\n
  6. Check all this into your codebase<\/li>\n<\/ol>\n

    Advantages<\/h2>\n