4 ms·

I think the issue here is that it adds so much complexity. There's a project called pip-tools (https://github.com/nvie/pip-tools https://github.com/nvie/pip-too

I think the issue here is that it adds so much complexity. There's a project called pip-tools (https://github.com/nvie/pip-tools https://github.com/nvie/pip-tools) that does a similar thing (generates a requirements.txt, test-requirements.txt etc) from a requirements.in files, so it serves the same purpose as a .lock but is backward compatible, much simpler, not subject to abuse by having it be actual code, and is machine parsable by any language. Having a more complex requirements system that what we have with requirements.txt is good, but at what cost? Is Python doing this just because other languages to it this way? I think it is actually

examancer 10y ago
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.

examancer 10y ago

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.