In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).

Say have docs/requirements-pip-tools.in

-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in

...

The intent is compiling this would produce docs/requirements-pip-tool.txt

But there is confusion as to which flag to use. It’s non-obvious.

constraint

Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!

Does not support:

  • editable mode (-e)

  • extras (e.g. coverage[toml])

Personal preference

  • always organize requirements files in folder(s)

  • don’t prefix requirements files with requirements-, just doing it here

  • DRY principle applies; split out constraints which are shared.

  • spoonbill@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    6 hours ago

    Constraints are useful for restricting build dependencies of your dependencies, especially if they follow PEP-518.

  • logging_strict@programming.devOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 hours ago

    A package’s requirements are left unlocked An app’s requirements are locked

    This doesn’t excuse app devs from excluding a requirements.in file