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.

  • logging_strict@programming.devOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    3 days ago

    A package’s requirements are left unlocked

    An app’s requirements are locked

    This doesn’t excuse app devs if an requirements.in file is not provided

    e.g. pip freeze > requirements.txt and forget

    This produces a lock file. Including indirect packages. The direct packages info is lost if a requirements.in is not provided.