9mo ago

constraint vs requirement. What's the difference?

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.

27 comments

Constraints are useful for restricting build dependencies of your dependencies, especially if they follow PEP-518.
- Was working under the assumption that everyone considered constraints (-c) to be non-negotiable required feature.
  If only have requirements (-r), in a centralized pyproject.toml, then how to tackle multiple specific dependency hell issues without causing a huge amount of interconnected clutter?
  
  Why do you need to have a centralized pyproject.toml?
Requirements are literally the packages your project requires to run,down to a specific version if you wish.
Constraints specifies what version of a package to install IF the package is required by your requirements, or by transitive requirement (required by packages you require). If package is not required, the constraint is not used.
I tend to use requirements file to list direct dependencies of my project and their versions. Constraints is useful to pin down and transitive dependencies to make sure they're not accidentally upgraded (repeatable builds) . Also if the 3rd party package drops a requirement you don't have to worry that it'll still be installed if it's still on your constraints. It'll simply not be installed.
- Great explanation of the most important difference
my personal preference is a pyproject.toml over that mess
- But pyproject.toml supports neither locking nor constraints.
  
  Woah! Was giving the benefit of the doubt. You blow my mind.
  The locking is very very specific to apps and dev environment.
  But lacking constraints is like cutting off an arm.
  
  Ah true, I had the wrong idea about this constraints file. What's your use case?
- my position is it's not messy enough
  Lets start off by admitting what the goal is.
  We all want to avoid dependency hell.
  Our primary interest is not merely cleaning up the mess of requirements files.
  Cleaning up the mess results in some unintended consequences:
  noise
  complexity
  confusion
  noise
  All the requirements information is in one place. Sounds great until want to tackle and document very specific issues.
  Like when Sphinx dropped support for py39, myst-parser restricted the Sphinx upper bound version, fixed it in a commit, but did not create a release.
  Or cffi, every single commit just blows our mind. Adding support for things we all want. So want to set a lower bound cffi version.
  My point being, these are all specific issues and should be dealt with separately. And when it's no longer relevant, know exactly what to remove. Zero noise.
  complexity
  When things go horribly wrong, the wrapper gets in the way. So now have to deal with both the wrapper and the issue. So there is both a learning curve, an API interface, and increased required know how.
  The simple answer here is, do not do that.
  confusion
  When a dependency hell issue arises, have to deal with that and find ourselves drawn to poetry or uv documentation. The issue has nothing to do with either. But we are looking towards them to see how others solve it, in the poetry or uv way.
  The only know-how that should be needed is whats in the pip docs.
  Whats ur suggestion?
  Would prefer to deal with dependency hell before it happens. To do this, the requirements files are broken up, so they are easier to deal with.
  Centralizing everything into pyproject.toml does the opposite.
  Rather than dealing with the issue beforehand, get to deal with it good and hard afterwards.
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.

27 comments