True. This is an ongoing problem with packaging discussions.
It would, but it’s typically been near-impossible to do. I’d love to get such input (in an unbiased form - I’d be cautious about anecdotal information from groups that potentially have a level of bias, such as experienced developers, or users of a particular tool, etc). But I don’t want to block progress on chasing after an unattainable ideal.
That’s a matter of opinion, as I’m sure you’ll agree.
Agreed, but it’s also not a strong argument for TOML-style syntax. Any format that includes quotes is IMO a potential usability problem, given the quirks of quoting in different shells. The best I can say here is that of the two proposed formats, PEP 508 uses less special characters. But I don’t feel that either proposal can reasonably claim to be ideal for use on the command line. Inventing an additional, CLI-only, format may be even worse, though. Having said all that, this discussion is not about CLI usage, “can it be copied to the CLI” is an incidental question at best.
Correct. I find the PEP 508 version far easier to read. So there’s little point to the comparison, as all it does is confirm that people have different views.
I’m not aware of pip/setuptools users complaining about PEP 508 format, either. But I haven’t investigated much, so if we really care about that sort of data, we should do a proper survey.
True. But unless we get 100% consensus, it is always going to be the case that some tools will need to change to conform to the standard. I sympathise with the fact that Poetry deliberately chose to use something other than PEP 508, and so this would feel like a regression, but so far the arguments that convinced you to take the route you did with Poetry either haven’t been explained clearly enough in this discussion, or haven’t been sufficiently convincing to change people’s minds.
I think this is the key here. We don’t all agree on what to optimise for, so we keep circling round the same arguments - but no-one is convinced, because we all have different goals.
To give a personal perspective, I consider it “obvious” that the following are the highest priorities:
- Simple cases can be written with minimal syntax overhead.
- Knowledge of how to write dependencies in
pyproject.tomlshould be transferrable to other situations (CLI usage, other configuration files, metadata, …) and vice versa.
Conversely, I don’t put any priority on (for example):
- Making it easy to specify complex cases.
- Similarity to other language ecosystems.
- What libraries tools need to use to parse the data.
There are plenty of other aspects that come somewhere in the middle (teachability, discoverability, for example).