Rename `pep517` to `pyproject-hooks`, and trim functionality

[pradyunsg]

This could be somewhat disruptive, but with #119, this project's name is objectively incorrect.

Given that this was originally written as a sample implementation of the standard and has since become the canonical place to provide wrappers/callers into pyproject.toml-based Python package builds, it might make sense to completely deprecate this package (not just the pep517.build/check interfaces, as discussed in #91) and move the wrappers into a separate package.

Let's switch to a more user-friendly name here, that better conveys the purpose of this package?

[pradyunsg]

xref pypa/pyproject-metadata#10

[takluyver]

I'm open to ideas for other names, but at present I tend to think that pep517 is still the clearest, least ambiguous way to refer to this. To my mind, PEP 517 defines the basic shape of an importable Python object with particular methods to build a package, and thus is the 'PEP 517 interface', even after other PEPs have added methods to this.

Though this does make me think that we should merge the relevant bits of PEPs 517 & 660 in a new specification document under https://packaging.python.org/specifications/ . 🙂

[pradyunsg]

I'm gonna check what names are available on Friday and try moving just the wrappers to that. I'm bit concerned about someone squatting a PyPI name before we can get to it, if I mention it publicly.

Yes to moving things. God, I wish we had a more streamlined process for the standards.

one day

[pradyunsg]

Alright. https://pypi.org/p/pyproject-hooks is a thing now (https://github.com/pradyunsg/pyproject-hooks).

[takluyver]

Thanks! Where do you want to go from here? Are you going to move pyproject-hooks to the PyPA namespace? Does it need a vote as a new project, or can we bypass that because it's really just a rename of an existing PyPA project? I'm happy for this project to point to pyproject-hooks as its successor, and eventually to be archived.

[pradyunsg]

Yup, that's basically the plan.

[pradyunsg]

It'll need a vote, and I'll initiate that over this week or early next year (depending on how my free time goes).

[takluyver]

I can initiate the vote if you'd like. 🙂

[jaraco]

My preference would be to rename the project in Github, to allow continuity of references (Github will redirect) and to limit cruft.

[pradyunsg]

OK, let's do a rename then. :)

Here's what I have in mind for this:

• Rename the project in this codebase, via a PR. Also drop the deprecated features as a part of the renaming.
• Setup a fork, update main on that to be the commit of the final release with pep517 and add a message to the docs that pep517 has been renamed.
• Update the repository name, once the PR lands.
• Point pep517.rtfd.io to that fork.

[pradyunsg]

#151 does the first step, while also removing the bits of functionality that we wanted to remove/deprecate.

[pradyunsg]

@pfmoore @takluyver Could one of you disable latest from pep517.readthedocs.org?

That would be unchecking "Active" on https://readthedocs.org/dashboard/pep517/version/latest/edit/?