Generalize the ABI provider into a generic "reserved provider", v2

[mgorny]

Same as #89, except that the identifier is explicitly given to builtin key, rather than reusing the namespace. IMO that's even more consistent design, and makes the builtin key meaningful rather than incidental.

[read-the-docs-community]

Documentation build overview

📚 wheelnext-peps | 🛠️ Build #34799820 | 📁 Comparing 733cc9e against latest (344e589)

  🔍 Preview build  

51 files changed · + 6 added · ± 45 modified

+ Added

• pep-0845/index.html
• pep-0846/index.html
• pep-0847/index.html
• pep-9999/index.html
• pep-0825/appendix-metadata-consistency/index.html
• pep-9999/appendix-variant-json-schema/index.html

± Modified

• index.html
• numerical/index.html
• pep-0000/index.html
• pep-0426/index.html
• pep-0501/index.html
• pep-0534/index.html
• pep-0545/index.html
• pep-0585/index.html
• pep-0604/index.html
• pep-0654/index.html
• and 35 more...

[DEKHTIARJonathan]

Question/Feedback

can you explain why doing this

"abi": {
   "builtin": "abi_dependency"
}

instead of this:

"abi_dependency": {
   "builtin": true
}

I get that it allows to name abi_dependency to be "whatever you want" - but I really don't see why doing that ... It's just feels unnecessarily "heavy".

Or that conceptually the namespace and name of the package are not necessarily 1:1 - but I also remember Ralf saying some time ago that we should try to force ecosystem consistency when possible. This seems one of these cases where we should enforce abi_dependency namespace for everybody.

[mgorny]

1. It's more consistent with how namespaces aren't hardcoded or significant for other kinds of providers.
2. It lets people create new builtin providers without risking namespace collisions with other providers.
3. It avoids adding a field whose only valid value is true. (Given that we say only one of the three keys can be specified.)

It's not a big deal, it just felt more solid as a proposal. Makes this look less like an afterthought.

[DEKHTIARJonathan]

OK ... Feels a little more difficult to read but fair enough ...

[DEKHTIARJonathan]

Suggested change

	internal provider implementation if supported, or assume that no
	internal provider implementation if supported, otherwise assume that no

[mgorny]

There's already a "otherwise" below.

[DEKHTIARJonathan]

Suggested change

	features are compatible if not. Otherwise, proceed to step 4.
	features are compatible. Otherwise, proceed to step 4.

[DEKHTIARJonathan]

Specifically because we say that "Tools that choose to implement them
MUST follow the PEP implementing them." I would recommend kicking everything after this paragraph out the PEP.

Especially that now we don't need to reserve a name like we used to have before your builtin idea.

[rgommers]

I caught up with these builtin changes only now - for the record, I like the generalization, 👍🏼 from me.