Confirmed users
324
edits
WebDev/Deployments: Difference between revisions
differentiated requirements for library files
(differentiated requirements for library files) |
|||
| Line 7: | Line 7: | ||
* to have them deployed quickly and securely internally | * to have them deployed quickly and securely internally | ||
==Using requirements== | ==Using requirements for a deployment== | ||
For a deployed product (such as a website) specify its packages in requirements files. We recommend splitting the packages down into separate file for separate roles, for example: requirements/dev.text, requirements/prod.txt, and requirements/test.txt (those needed only for CI builds). | |||
All requirements should be pinned, | All requirements should be pinned, e.g.: | ||
foo==0.3 | foo==0.3 | ||
Use of <code>>=</code> or not pinning to a version is not recommended. This | Use of <code>>=</code> or not pinning to a version is not recommended. This could result in deploying broken, untested versions of packages to production or during local development. | ||
When running pip use the flag: <code>--no-deps</code>. This ensures that packages will not pull in more untested versions of packages. It also means that the requirements files are a definitive source of packages used. This allows security faster audits of who is using what package. | When running pip use the flag: <code>--no-deps</code>. This ensures that packages will not pull in more untested versions of packages. It also means that the requirements files are a definitive source of packages used. This allows security faster audits of who is using what package. | ||
{{note|Packages on PyPI can be removed then replaced so even pinning a version does not mean it can be trusted if you are not using the internal mirror.}} | {{note|Packages on PyPI can be removed then replaced so even pinning a version does not mean it can be trusted if you are not using the internal mirror.}} | ||
==Using requirements for a library== | |||
When building a library for deployed products to install, we recommend creating a single requirements.txt file in the root of the project. Unlike deployed products, do not pin requirements for libraries. Instead, keep them loose like: | |||
django | |||
django-aesfield | |||
If you require certain versions, specify the minimum version required: | |||
django>=1.4 | |||
Using loose requirements for libraries helps to avoid version conflicts when a deployed product has multiple packages that both require django (or some common package). | |||
==Internal package server== | ==Internal package server== | ||