[epage]

Until you need a platform or Python version agnostic lock file. pip-tools compiles the list for your current environment which makes it limited.

[orzig]

This is interesting; can you expand or point to some documentation? I don’t have this design requirement right not, so I’m trying to understand any growing pains I might be locking myself into

[jrib]

Not OP, but in our case, there was a package that had a dependency for python3.6 but not for python3.8.

Our production environment was python3.6. Devs rebuilt the requirements.txt with python3.8.

When we attempted to use the requirements.txt with python3.6, we couldn't because a package was missing (and we installed with `--require-hashes`). The dependency was `importlib-metadata` iirc.

But googling around, here's an example of a package that has dependencies that changed based on the python version: https://github.com/pypa/pep517/blob/main/pyproject.toml#L13 .

In our case, we just made sure to rebuild the requirements.txt with the version that matched our production; not sure if there's a "nice" way to support multiple versions with pip-tools.

[sinsterizme]

As you discovered, the actual fix is making sure your production and development python environments match. As for platform discrepancies, docker helps with this

[BerislavLopac]

> platform or Python version agnostic lock file

I might be splitting hairs here, but this seems like an oxymoron: if it's agnostic on anything, it's not really a lock file.