[globular-toast]

> Of course we, like all other python projects, don't support using other dependency versions then the ones in the requirements.txt file. So when someone just uses a different minor version of django, stuff breaks

That sounds wrong. A Python package should not have a requirements.txt file at all. A requirements.txt file is for "freezing" and fully reproducing an environment (ie. in a virtualenv or docker container). This is useful for certain applications like deploying services or sharing notebooks etc. It is not for packages. A package should document its requirements via setup.py/pyproject.toml and do so in the loosest way possible. Django uses semver and Django apps don't generally need to pin to minor versions.

Stuff like this is why people think Python packaging is worse than it really is.

[scandinavian]

The application is not distributed via pypi, nor is it installed as a package and thus have no setup.py file.

> A requirements.txt file is for "freezing" and fully reproducing an environment (ie. in a virtualenv or docker container).

No, it's just for specifying which versions of packages should be installed by pip. There's no such concept of a lock file with pip. Poetry and the likes have lock files though.

[duped]

> There's no such concept of a lock file with pip.

There's the --require-hashes flag and the ability to specify the hashes in your requirements.txt

[SAI_Peregrinus]

Django doesn't use semver. It uses a Major.Feature.Patch release notation, not Major.Minor.Patch. Feature releases usually contain breaking changes, where SemVer minor releases never should.

[reuben364]

With my ignorance of the python packaging ecosystem, I was always under the impression that requirements.txt was the version constraints, not the lock file.