I like the enthusiasm!
Because the official spec is useless if the tool authors don’t follow it. It’s much easier to add an official spec for something that already de facto happens because the tools already support it. Ideally the standards would follow established practice in the first instance rather than drive it. Of course often that approach doesn’t work…
Standards are nothing unless tools decide to follow them, so either way the tool authors need to chime in and say they are OK with this. The only functional difference is who to do the get together; the extra layer can be useful in some situations, but not here.
I don’t see a reason mentioned here to push the workflow tools to collaborate.
Can I suggest mine? It is very difficult right now to suggest poetry, hatch, or whatnot to an existing projects in at my team(s). There’s a buy-in for each one of them each using their own standard representing metadata and behaving in different ways (development dependencies for one). Because they’re frontend/workflow tools, fundamentally, there doesn’t have to be any buy-in.
There is no value in any discussion here if the results of that discussion are not implemented by the tools. A standard to write development dependencies somewhere is useless if the tools do not use it.
Of course there is value: proposing and discussing a solution allow the tools authors to know **what ** to implement
Let me clarify, I mean I do not see a reason mentioned here that pushes workflow tool to collaborate.
For example, @Zomatree’s reason
if every tool needs to reinvent dev dependencies then it should be formally added to the pyproject specification.
is not convincing for existing tooling projects since they’ve already done the work already.