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/?

[pradyunsg]

I'll file a follow up PR doing a round of documentation updates.

[pfmoore]

I think I've done it, but note the message here.  (Edit: Images don't seem to make it through email...) (Another edit: Or cut and paste. No idea what's going on here, you'll have to follow the link, sorry...)

[pradyunsg]

Email replies do not support Markdown

Let me to inline that in a non-email reply:

[pradyunsg]

Hmmm... Could you add me as a collaborator on that project?

[pfmoore]

Email replies do not support Markdown

And it looks like the reply somehow retains the information that it came from email even after it's edited. Weird.

Could you add me as a collaborator on that project?

Done.

[ketozhang]

Update the description as well

API to call PEP 517 hooks for building Python packages

I got confused this package was only for build system metadata.

[pradyunsg]

@ketozhang Yup, updating the docs is literally what I'm working on right now. :)

---

https://readthedocs.org/projects/pyproject-hooks/ is up now, pointed at the same repository as https://readthedocs.org/projects/pep517/ -- i.e. this repository.

My plan for now is to set up the pep517.rtfd.io link to point to a (to-be-created) legacy branch, which would be used to publish the docs for the last release of pep517; with warnings added throughout to tell people to stop using it since that package name is now unsupported and will no longer get updates.

[pradyunsg]

I've done a bunch of things around the documentation now...

• I've pushed a legacy branch (same commit as the last tag) and setup branch protection on that to require PRs to be filed to push to that branch.
• pep517 on RTD:
  • no longer builds pull requests.
  • no longer has a stable variant of the documentation.
  • the latest variant of the documentation points to the legacy branch.
• pyproject-hooks on RTD:
  • @pfmoore @takluyver You've both been invited to pyproject-hooks on RTD. You should have an email about this.
  • builds pull requests.
  • has stable (last tag) and latest (main branch) variants.

With those and the manual updates to the GitHub repo description/url, I reckon that's all most of the non-code stuff around the documentation. The next steps are:

• Rework the documentation based on the renaming of the project #154 -- a sweeping documentation update, since we have the ability to use novel links and I like how things ended up structured for installer. 😅
• Add warnings on all documentation about pep517 being unsupported #155 -- adding warnings and messages to pep517 on RTD, that users should move to pyproject-hooks instead.
• Various cleanup and prepare for 1.0 release #152 to cut a release of pyproject-hooks!

[takluyver]

Thanks @pradyunsg for dealing with most of the admin stuff around the name change. 🙂

[Secrus]

would #90 be considered as part of 1.0 release plan?

[pradyunsg]

IMO, it's not on the critical path. There's no reason why that couldn't be tackled in a follow up or even as a part of that -- it's certainly easier, now that the entire API surface is significantly smaller. :)

[pradyunsg]

Added the old name here, since "this project" is now pyproject-hooks. :)

[pradyunsg]

Here's a draft announcement for discuss.python.org, since this is worth publicising at least there:

Title: `pep517` is now `pyproject-hooks`!
Category: Packaging

The `pep517` package on PyPI has been renamed to `pyproject-hooks`.

Along with this rename, the functionality that had equivalents in `build` has been removed from this package. And, as the name suggests, the project is now meant to provide a shared implementation of calling code for pyproject.toml-based build backend hooks.

---

For those curious about the specifics around the rename:

- The GitHub repository has been [renamed](https://github.com/pypa/pyproject-hooks). Going to the [old repository](https://github.com/pypa/pep517) will redirect users to the new repository name automatically.
- The documentation has been revamped as well [[docs]](https://pyproject-hooks.readthedocs.io/en/latest/). The `pep517` documentation is still available [at the same location as before](https://pep517.readthedocs.io/en/latest/), with an extra pointer to the replacement projects.
- The source code for the `pep517` project is available on the [`legacy` branch of the repository](https://github.com/pypa/pyproject-hooks/tree/legacy).

@takluyver Please feel welcome to make a post about this (that doesn't need to be based off of my draft above) when you cut a release. But, please also don't feel obligated to do so -- I'm more than happy to post something based off of the above once the release is made. :)

[pradyunsg]

Adding a link to https://discuss.python.org/t/pep517-is-now-pyproject-hooks/21275, for posterity.