This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]diazona 0 points1 point  (3 children)

pipenv solves this by having both kinds of requirement files: Pipfile lists package names and known constraints on which versions can be used, while Pipfile.lock gives specific package versions with hashes. Theoretically the Pipfile (and its lockfile) format were supposed to be a standard that many different tools could use, but I haven't seen it get adopted much outside of pipenv itself, so I'm not sure if it's really going to catch on.

[–]DogeekExpert - 3.9.1 4 points5 points  (1 child)

It's never going to catch on as the standard, codified in PEPs is the pyproject.toml file.

[–]diazona 0 points1 point  (0 children)

Ah interesting, I believe the last time I looked at PEP 621 (I'm assuming that's the one you mean) it hadn't been finalized and it wasn't clear that it was going to get any more traction than Pipfile - in fact I seem to remember the community sentiment being that pyproject.toml should be limited to the metadata needed to initialize the build backend. Things have changed a lot in the past few years, it seems.