Closed fridex closed 4 years ago
Hey! A revolutionary idea, what about full dropping requirements.txt
and embracing Pipfile{,.lock}
instead. From start to finish. Let's make it a habit. And there is no need for converting to pipenv later on etc...
What do you think @durandom @MichaelClifford ?
Hey! A revolutionary idea, what about full dropping
requirements.txt
and embracingPipfile{,.lock}
instead. From start to finish. Let's make it a habit. And there is no need for converting to pipenv later on etc...What do you think @durandom @MichaelClifford ?
I'm good. Personally I never use requirement.txt
anyways.
Hey! A revolutionary idea, what about full dropping
requirements.txt
and embracingPipfile{,.lock}
instead. From start to finish. Let's make it a habit. And there is no need for converting to pipenv later on etc...
We use requirements.txt to state direct dependencies of an application (together with version range specification to restrict usable versions). Pipfile states direct dependencies as well, the issue is with TOML in which Pipfile uses. TOML is not in the standard library (a proposal was planed though), so reading Pipfile in setup.py will result in failures in environments where toml/pytoml packages are not installed.
Pipfile.lock states all the dependencies in a pinned form. This is good for components that are deployed within the cluster or applications, but if you release a library with all the dependencies locked, you can easily make it not usable in projects (as resolver might not find versions of dependencies that would be satisfied with other libraries).
To reduce issues with Pipfile/requirements.txt files, we introduced a bot that can manage these two files and keep them in sync in your repo.
CC @saisankargochhayat
Also, do not use pip freeze for obtaining all the dependencies.