from an exploration of issues on the pipenv repo: ( pypa/pipenv#954 pypa/pipenv#598 )
The standard is to commit it for applications, for libraries, less so
Given that black is typically used as a third party tool in workflows and environments, in this case I would consider black a library: its not the only thing being installed to an environment.
This means that the contributor libraries are pinned to a very different verision than what could be installed.
In addition, take the recent versioning problem with regex. This should have been caught and found before release, by testing with the lowest supported versions of dependencies. With the pipfile.lock, all of the dependencies are the same for every contributor, and during the development cycle all dependencies are the same.
When installed from pypi, pip or the installation tool uses its own dependency resolver that matches the provided requirements--which may or may not necessarily match the versions in pipfile.lock
Given all of this information, I am a believer that pipfile.lock should not actually be commited to version control for black.
I also believe that the lowest supported dependencies should be used for testing, but that's a different argument