How to specify dependencies: PEP 508 strings or a table in TOML?

[pganssle (Paul Ganssle)]

@pf_moore

PEP 631 includes some rather confusing wording, in that it says values must be an “array of strings or inline tables”, but then goes on to say that inline tables are for future expansion, and backends MUST error if they encounter inline tables “unless the specification is extended”. I consider this a pointless distinction, as making inline tables allowed can be done when (if!) the specification gets extended, so there’s no need to make an explicit provision now.

As a result, I interpret the spec as effectively saying that only an array of strings is allowed, and I would encourage @ofek (as PEP author) to clean up that part of the PEP to make that explicit. Doing so will not affect the decision on the PEP, which is based on my reading of the practical implication of the text.

Since I’m the one who suggested this change, I would like to argue for keeping it in or clarifying it differently. The reason for “this may be an array of strings” is that we were attempting to allow for a relatively smooth process of extending the spec from projects other than backends. I specifically asked for clarification on the point of whether the spec is aimed at non-backend tools as well and you said it was.

For backends, I agree with your reasoning that we can deal with extensions to the spec as they come up, because anyone using new features would also choose a backend that supports the new features. For tools that consume other peoples’ projects, though, the situation is different, because an “analyze everything on github” tool may start breaking if we add an “extension” to the spec of this nature (since it is rejecting anything that’s not an array of strings).

My suggestion is that backends must throw an error (after all they don’t know what to do with the information), but non-backend tools should treat the field as dynamic (thus leaving it to the backend to decide what is and is not in spec.

In this case, I thought it was worth calling this out because “we might allow for an inline table instead of a string here” is a pretty versatile way to painlessly extend the spec, and pretty much the only one I envision us using (if we ever extend the spec by changing the type of a field rather than by adding new fields).

Obviously we can bump this from PEP 631 if we want to make it a more general principle in PEP 621 that out-of-spec fields are treated as dynamic and delegated to the backend for enforcing spec compliance.