I personally am of opinion that we should not have a such file format yet. Such file would be highly application specific, and mostly aimed at applications at best rather than library development. (e.g. I would like to have separate lint/format/tester/run environment both for my applications and libraries). pipenv e.g. though somehow thinks a single environment is all you need, which I’m not on board with yet.
Maybe we do or maybe we don’t. But I feel like we’re rushing ahead. First we would need to clearly define how source trees/distributions can tell their requirements (both install and extras) to frontends/tools, which we still lack as of today.
So I would propose let’s start with a PEP that defines how a build backend provides this information. We could extend for this the backend API defined under https://www.python.org/dev/peps/pep-0517/. We can/should probably do something that builds on what we already have for wheels, see https://www.python.org/dev/peps/pep-0566/#id11.
Now once we agreed how to provide library requirement information in general we can start iterating on how to provide it for an application that needs to merge/pin together essentially a list of these.
@pf_moore @pradyunsg @pganssle @dstufft @ncoghlan @steve.dower @dustin are probably a few of the people who should be involved in this