3 ms·

The purpose of a lock file is to separate the concepts of "acceptable versions" from "the list of last exact versions I used and were working". These are very d

The purpose of a lock file is to separate the concepts of "acceptable versions" from "the list of last exact versions I used and were working". These are very different things and requirements.txt doesn't do both without you getting really anal with your version requirements (and losing the benefits of less strict version requirements).

Groxx 10y ago
With pip-tools, requirements.txt is your lock file, and everything in it is pinned. It's built from an acceptable-versions input usually called "requirements.in".
- examancer 10y ago
  Interesting. I guess Pypa feels Python also needs a flexible DSL and dependency groups in addition to the pip-tools lock file solution.
  - Groxx 10y ago
    Probably, yeah. Though unless it's Real Python™ code, and can do lots of shenanigans, I don't see how it's more flexible. And all those shenanigans mean :'( in the same ways as setup.py. And if it's not Real Python™ and just a python-like declarative syntax, then why not just add the features to requirements.txt and the command-line, and maintain that parity? Dependency groups don't really mean an advantage to me. E.g. with pip-tools, on the code I work on, we've got 3 requirements*.txt files. One (requirements.txt) for prod, and ones for test/dev/any additional scopes you may want. Then you `-r requirements.txt` in requirements-dev.in (and -test), and you're guaranteed to maintain the same versions as production when resolving requirements-dev.txt, or have conflicts if something dev adds prevents that from working. In CI / build / etc you just install the single file that's relevant to you. Bundling groups into the file would be nice for not being able to make mistakes (our approach above requires you to compile things in order, for example), but that would have to weigh pretty heavily against breaking backwards compatibility and a very-simple DSL that already exists.

Groxx 10y ago

With pip-tools, requirements.txt is your lock file, and everything in it is pinned. It's built from an acceptable-versions input usually called "requirements.in".

examancer 10y ago
Interesting. I guess Pypa feels Python also needs a flexible DSL and dependency groups in addition to the pip-tools lock file solution.
- Groxx 10y ago
  Probably, yeah. Though unless it's Real Python™ code, and can do lots of shenanigans, I don't see how it's more flexible. And all those shenanigans mean :'( in the same ways as setup.py. And if it's not Real Python™ and just a python-like declarative syntax, then why not just add the features to requirements.txt and the command-line, and maintain that parity? Dependency groups don't really mean an advantage to me. E.g. with pip-tools, on the code I work on, we've got 3 requirements*.txt files. One (requirements.txt) for prod, and ones for test/dev/any additional scopes you may want. Then you `-r requirements.txt` in requirements-dev.in (and -test), and you're guaranteed to maintain the same versions as production when resolving requirements-dev.txt, or have conflicts if something dev adds prevents that from working. In CI / build / etc you just install the single file that's relevant to you. Bundling groups into the file would be nice for not being able to make mistakes (our approach above requires you to compile things in order, for example), but that would have to weigh pretty heavily against breaking backwards compatibility and a very-simple DSL that already exists.