PEP 621: how to specify dependencies?

[brettcannon]

@pradyunsg

I’m thinking of 2 separate PEPs (one w/ TOML tables, one w/ PEP 508) with PEP 621 deferring to whichever gets accepted.

That’s how I would suggest doing it, but I am definitely not writing either of those other PEPs.

@pf_moore

If you want a strong guide as to what I would find most persuasive, I’ll say this. Stop worrying about process, and about how to present the choice, and concentrate for now on getting an “exploded format” proposal that’s specific, documented, and agreeable to everyone who’s arguing for “exploded format”. Present a unified alternative. Stop worrying about persuading people who prefer PEP 508, and focus on clarifying what alternative you are suggesting.

Based on that, I think the idea of resolving this discussion with a final answer instead of PEP 621 becoming a recommendation/guide is very much going to come down to who is willing to volunteer to write a PEP 508-based PEP and an exploded table PEP just on the topic of how to write them down in a TOML file.

How about this: if people can get themselves organized enough to have a draft proposal being actively discussed as a topic here by Tuesday, September 8th then we can consider this idea of keeping PEP 621 a standard alive (that’s in 3 weeks). So this would be mostly a forcing function for people to organize themselves (on a separate topic!) and show dedication by showing forward progress on these other PEPs. But if people can’t get themselves organized that quickly then I would consider this dead due to lack of motivation and PEP 621 would no longer on the standards track and instead will either be withdrawn or touched up to be an informational PEP.

Does that work for people (and specifically @pf_moore)?

@pf_moore

This is why I just say the PEP is “weak” - it doesn’t need to act as a sales push for the new format, but it could do better at explaining the reasons to people in that sort of situation.

Fair enough, although the motivation section has already been rewritten I think twice now based on feedback from people so I don’t know how to improve it without simply culling less motivating reasons and going all-in on the “you only need to document it once” argument as @pganssle pointed out (which I’m fine with, but I don’t want to do the work if that won’t be beneficial).

@pganssle

would be to recast PEP 621 as an informational PEP describing the design decisions that went into it and how you can apply them for your backend.

True, it could just change its type instead of being withdrawn if it was reworked to phrase its motivation that way. I’m fine with this if the idea of separate PEPs on the topics are not enough to reach a conclusion. And even if dueling PEPs are written and this is still the way we go then at least we have written out suggestions on how people handle either format for dependencies.