We are currently solving the following issue within our repository. Here is the issue text:
--- BEGIN ISSUE ---
Decide what PEPs fall under `Topic: Packaging` and act accordingly
Right now, as originally discussed in #2096 , there seem to be two plausible interpretation of what qualifies for the `Topic: Packaging` label: PEPs that _relate_ to packaging in some direct way, and PEPs that apply to packaging ecosystem (as opposed to the stdlib), and are thus discussed primarily on packaging community fora and accepted/rejected by the relevant packaging-community standing PEP delegate.

In particular, given PEP 632 (PEP-632), on deprecating and removing `disutils`, was removed from packaging at the request of @zooba for relating to the core stdlib, this would seem to suggest that PEP 453 (PEP-453) and PEP 477 (PEP-477), on `ensurepip` and its backport to Python 2.7, respectively, should also be removed by the same standard (or, alternatively, PEP 632 restored).

Presuming consensus can be reached prior to its merging, I can implement this on the existing #2690 , given it makes a number of related improvements/refinements to the packaging-tagged PEP headers.

<details>

<summary>Relevant discussion from #2096 (click to expand)</summary>

@pfmoore 

> this is a core Python PEP, not a packaging PEP, and like @dstufft noted, I don't think we tend to modify those after approval.

@CAM-Gerlach 

> In that case, as originally discussed on https://github.com/python/peps/pull/2656 and done for PEP 632 ([PEP-632](https://peps.python.org/632)), maybe we should drop Topic: Packaging from this PEP as well as the related PEP 477 ([PEP-477](https://peps.python.org/477)) ? I can do it in https://github.com/python/peps/pull/2690 since its closely related to the other changes in that PR (also, your input there on updating PEP 262 ([PEP-262](https://peps.python.org/262))'s status to reflect reality would be helpful).

@pfmoore 

> I don't know on that. It's packaging related in the sense that it is about packaging tools, so if people are looking for things that are "about" packaging, it does belong in the Packaging topic. But it's not a "PyPA specification" in the sense defined [here](https://www.pypa.io/en/latest/specifications/), which is why I said that the normal PEP rules about modifications should apply, rather than the PyPA-specific process. Ultimately, I'm not actually sure what the rules are for when a PEP qualifies as being in the Packaging topic...

@CAM-Gerlach 

> Yeah, exactly. That basically comes down to whether a Topic is considered more of a "Category" (i.e. the former), or a "Track" (i.e. the latter). I presented both alternatives at the beginning of the discussion, and both were favored at different points in its evolution; the initial consensus in the Discourse thread was something more like a "Track", but on the PR and naming of the "Topic" header that was eventually implemented (that allows multiple topics per PR), it ended up basically the latter, at least nominally.
>
> However, with PEP 632 ([PEP-632](https://peps.python.org/632)) being removed at the behest of @zooba in https://github.com/python/peps/pull/2636#discussion_r898173875 , given these two PEPs basically just concern adding/backporting a utility module from the core standard library rather than PyPA/PyPI standards, it seems to me to not make sense to keep those PEPs but not another very similar one about the deprecation and removal of what was the core packaging module. So, I suggest either removing those two, or adding back PEP 632.

@pradyunsg 

> Alternatively, we can defer doing anything here until the authors have a concern with being listed under the packaging index as well or till we see/identify more instances of something like this? In any case, this discussion should move to a separate issue IMO.

@zooba 

> I think this is in the same boat as PEP 632, and shouldn't be tagged as a packaging PEP.
>
> As a proposal of the rule I'd use, if we'd let the packaging delegate (i.e. Paul, right now) decide without going to python-dev or the SC, then it's a packaging PEP. Whether something is added to the standard library clearly falls outside of this scope, and so this PEP is standards track and not packaging.

</details>

--- END ISSUE ---

Below are some code segments, each from a relevant file. One or more of these files may contain bugs.
--- BEGIN FILES ---
Path: `pep_sphinx_extensions/pep_zero_generator/constants.py`
Content:
```
1 """Holds type and status constants for PEP 0 generation."""
2 
3 STATUS_ACCEPTED = "Accepted"
4 STATUS_ACTIVE = "Active"
5 STATUS_DEFERRED = "Deferred"
6 STATUS_DRAFT = "Draft"
7 STATUS_FINAL = "Final"
8 STATUS_PROVISIONAL = "Provisional"
9 STATUS_REJECTED = "Rejected"
10 STATUS_SUPERSEDED = "Superseded"
11 STATUS_WITHDRAWN = "Withdrawn"
12 
13 # Valid values for the Status header.
14 STATUS_VALUES = {
15     STATUS_ACCEPTED, STATUS_PROVISIONAL, STATUS_REJECTED, STATUS_WITHDRAWN,
16     STATUS_DEFERRED, STATUS_FINAL, STATUS_ACTIVE, STATUS_DRAFT, STATUS_SUPERSEDED,
17 }
18 # Map of invalid/special statuses to their valid counterparts
19 SPECIAL_STATUSES = {
20     "April Fool!": STATUS_REJECTED,  # See PEP 401 :)
21 }
22 # Draft PEPs have no status displayed, Active shares a key with Accepted
23 HIDE_STATUS = {STATUS_DRAFT, STATUS_ACTIVE}
24 # Dead PEP statuses
25 DEAD_STATUSES = {STATUS_REJECTED, STATUS_WITHDRAWN, STATUS_SUPERSEDED}
26 
27 TYPE_INFO = "Informational"
28 TYPE_PROCESS = "Process"
29 TYPE_STANDARDS = "Standards Track"
30 
31 # Valid values for the Type header.
32 TYPE_VALUES = {TYPE_STANDARDS, TYPE_INFO, TYPE_PROCESS}
33 # Active PEPs can only be for Informational or Process PEPs.
34 ACTIVE_ALLOWED = {TYPE_PROCESS, TYPE_INFO}
35 
36 # map of topic -> additional description
37 SUBINDICES_BY_TOPIC = {
38     "packaging": """\
39 The canonical, up-to-date packaging specifications can be found on the
40 `Python Packaging Authority`_ (PyPA) `specifications`_ page.
41 Packaging PEPs follow the `PyPA specification update process`_.
42 They are used to propose major additions or changes to the PyPA specifications.
43 
44 .. _Python Packaging Authority: https://www.pypa.io/
45 .. _specifications: https://packaging.python.org/en/latest/specifications/
46 .. _PyPA specification update process: https://www.pypa.io/en/latest/specifications/#specification-update-process
47 """,
48     "release": """\
49 A PEP is written to specify the release cycle for each feature release of Python.
50 See the `developer's guide`_ for more information.
51 
52 .. _developer's guide: https://devguide.python.org/devcycle/
53 """,
54     "typing": """\
55 Many recent PEPs propose changes to Python's static type system
56 or otherwise relate to type annotations.
57 They are listed here for reference.
58 """
59 }
60
```
--- END FILES ---

Please first localize the bug based on the issue statement, and then generate a patch according to the `git diff` format fenced by three backticks.

Here is an example:

```diff
diff --git a/examples/server_async.py b/examples/server_async.py
--- a/examples/server_async.py
+++ b/examples/server_async.py
@@ -313,4 +313,4 @@
 
 
 if __name__ == "__main__":
-    asyncio.run(run_async_server("."), debug=True)
+    asyncio.run(run_async_server(), debug=True)
diff --git a/examples/server_sync.py b/examples/server_sync.py
--- a/examples/server_sync.py
+++ b/examples/server_sync.py
@@ -313,5 +313,5 @@
 
 
 if __name__ == "__main__":
-    server = run_sync_server(".")
+    server = run_sync_server()
     server.shutdown()

```

diff --git a/pep_sphinx_extensions/pep_zero_generator/constants.py b/pep_sphinx_extensions/pep_zero_generator/constants.py
--- a/pep_sphinx_extensions/pep_zero_generator/constants.py
+++ b/pep_sphinx_extensions/pep_zero_generator/constants.py
@@ -36,10 +36,10 @@
 # map of topic -> additional description
 SUBINDICES_BY_TOPIC = {
     "packaging": """\
-The canonical, up-to-date packaging specifications can be found on the
-`Python Packaging Authority`_ (PyPA) `specifications`_ page.
 Packaging PEPs follow the `PyPA specification update process`_.
 They are used to propose major additions or changes to the PyPA specifications.
+The canonical, up-to-date packaging specifications can be found on the
+`Python Packaging Authority`_ (PyPA) `specifications`_ page.
 
 .. _Python Packaging Authority: https://www.pypa.io/
 .. _specifications: https://packaging.python.org/en/latest/specifications/

{"golden_diff": "diff --git a/pep_sphinx_extensions/pep_zero_generator/constants.py b/pep_sphinx_extensions/pep_zero_generator/constants.py\n--- a/pep_sphinx_extensions/pep_zero_generator/constants.py\n+++ b/pep_sphinx_extensions/pep_zero_generator/constants.py\n@@ -36,10 +36,10 @@\n # map of topic -> additional description\n SUBINDICES_BY_TOPIC = {\n     \"packaging\": \"\"\"\\\n-The canonical, up-to-date packaging specifications can be found on the\n-`Python Packaging Authority`_ (PyPA) `specifications`_ page.\n Packaging PEPs follow the `PyPA specification update process`_.\n They are used to propose major additions or changes to the PyPA specifications.\n+The canonical, up-to-date packaging specifications can be found on the\n+`Python Packaging Authority`_ (PyPA) `specifications`_ page.\n \n .. _Python Packaging Authority: https://www.pypa.io/\n .. _specifications: https://packaging.python.org/en/latest/specifications/\n", "issue": "Decide what PEPs fall under `Topic: Packaging` and act accordingly\nRight now, as originally discussed in #2096 , there seem to be two plausible interpretation of what qualifies for the `Topic: Packaging` label: PEPs that _relate_ to packaging in some direct way, and PEPs that apply to packaging ecosystem (as opposed to the stdlib), and are thus discussed primarily on packaging community fora and accepted/rejected by the relevant packaging-community standing PEP delegate.\r\n\r\nIn particular, given PEP 632 (PEP-632), on deprecating and removing `disutils`, was removed from packaging at the request of @zooba for relating to the core stdlib, this would seem to suggest that PEP 453 (PEP-453) and PEP 477 (PEP-477), on `ensurepip` and its backport to Python 2.7, respectively, should also be removed by the same standard (or, alternatively, PEP 632 restored).\r\n\r\nPresuming consensus can be reached prior to its merging, I can implement this on the existing #2690 , given it makes a number of related improvements/refinements to the packaging-tagged PEP headers.\r\n\r\n<details>\r\n\r\n<summary>Relevant discussion from #2096 (click to expand)</summary>\r\n\r\n@pfmoore \r\n\r\n> this is a core Python PEP, not a packaging PEP, and like @dstufft noted, I don't think we tend to modify those after approval.\r\n\r\n@CAM-Gerlach \r\n\r\n> In that case, as originally discussed on https://github.com/python/peps/pull/2656 and done for PEP 632 ([PEP-632](https://peps.python.org/632)), maybe we should drop Topic: Packaging from this PEP as well as the related PEP 477 ([PEP-477](https://peps.python.org/477)) ? I can do it in https://github.com/python/peps/pull/2690 since its closely related to the other changes in that PR (also, your input there on updating PEP 262 ([PEP-262](https://peps.python.org/262))'s status to reflect reality would be helpful).\r\n\r\n@pfmoore \r\n\r\n> I don't know on that. It's packaging related in the sense that it is about packaging tools, so if people are looking for things that are \"about\" packaging, it does belong in the Packaging topic. But it's not a \"PyPA specification\" in the sense defined [here](https://www.pypa.io/en/latest/specifications/), which is why I said that the normal PEP rules about modifications should apply, rather than the PyPA-specific process. Ultimately, I'm not actually sure what the rules are for when a PEP qualifies as being in the Packaging topic...\r\n\r\n@CAM-Gerlach \r\n\r\n> Yeah, exactly. That basically comes down to whether a Topic is considered more of a \"Category\" (i.e. the former), or a \"Track\" (i.e. the latter). I presented both alternatives at the beginning of the discussion, and both were favored at different points in its evolution; the initial consensus in the Discourse thread was something more like a \"Track\", but on the PR and naming of the \"Topic\" header that was eventually implemented (that allows multiple topics per PR), it ended up basically the latter, at least nominally.\r\n>\r\n> However, with PEP 632 ([PEP-632](https://peps.python.org/632)) being removed at the behest of @zooba in https://github.com/python/peps/pull/2636#discussion_r898173875 , given these two PEPs basically just concern adding/backporting a utility module from the core standard library rather than PyPA/PyPI standards, it seems to me to not make sense to keep those PEPs but not another very similar one about the deprecation and removal of what was the core packaging module. So, I suggest either removing those two, or adding back PEP 632.\r\n\r\n@pradyunsg \r\n\r\n> Alternatively, we can defer doing anything here until the authors have a concern with being listed under the packaging index as well or till we see/identify more instances of something like this? In any case, this discussion should move to a separate issue IMO.\r\n\r\n@zooba \r\n\r\n> I think this is in the same boat as PEP 632, and shouldn't be tagged as a packaging PEP.\r\n>\r\n> As a proposal of the rule I'd use, if we'd let the packaging delegate (i.e. Paul, right now) decide without going to python-dev or the SC, then it's a packaging PEP. Whether something is added to the standard library clearly falls outside of this scope, and so this PEP is standards track and not packaging.\r\n\r\n</details>\n", "before_files": [{"content": "\"\"\"Holds type and status constants for PEP 0 generation.\"\"\"\n\nSTATUS_ACCEPTED = \"Accepted\"\nSTATUS_ACTIVE = \"Active\"\nSTATUS_DEFERRED = \"Deferred\"\nSTATUS_DRAFT = \"Draft\"\nSTATUS_FINAL = \"Final\"\nSTATUS_PROVISIONAL = \"Provisional\"\nSTATUS_REJECTED = \"Rejected\"\nSTATUS_SUPERSEDED = \"Superseded\"\nSTATUS_WITHDRAWN = \"Withdrawn\"\n\n# Valid values for the Status header.\nSTATUS_VALUES = {\n    STATUS_ACCEPTED, STATUS_PROVISIONAL, STATUS_REJECTED, STATUS_WITHDRAWN,\n    STATUS_DEFERRED, STATUS_FINAL, STATUS_ACTIVE, STATUS_DRAFT, STATUS_SUPERSEDED,\n}\n# Map of invalid/special statuses to their valid counterparts\nSPECIAL_STATUSES = {\n    \"April Fool!\": STATUS_REJECTED,  # See PEP 401 :)\n}\n# Draft PEPs have no status displayed, Active shares a key with Accepted\nHIDE_STATUS = {STATUS_DRAFT, STATUS_ACTIVE}\n# Dead PEP statuses\nDEAD_STATUSES = {STATUS_REJECTED, STATUS_WITHDRAWN, STATUS_SUPERSEDED}\n\nTYPE_INFO = \"Informational\"\nTYPE_PROCESS = \"Process\"\nTYPE_STANDARDS = \"Standards Track\"\n\n# Valid values for the Type header.\nTYPE_VALUES = {TYPE_STANDARDS, TYPE_INFO, TYPE_PROCESS}\n# Active PEPs can only be for Informational or Process PEPs.\nACTIVE_ALLOWED = {TYPE_PROCESS, TYPE_INFO}\n\n# map of topic -> additional description\nSUBINDICES_BY_TOPIC = {\n    \"packaging\": \"\"\"\\\nThe canonical, up-to-date packaging specifications can be found on the\n`Python Packaging Authority`_ (PyPA) `specifications`_ page.\nPackaging PEPs follow the `PyPA specification update process`_.\nThey are used to propose major additions or changes to the PyPA specifications.\n\n.. _Python Packaging Authority: https://www.pypa.io/\n.. _specifications: https://packaging.python.org/en/latest/specifications/\n.. _PyPA specification update process: https://www.pypa.io/en/latest/specifications/#specification-update-process\n\"\"\",\n    \"release\": \"\"\"\\\nA PEP is written to specify the release cycle for each feature release of Python.\nSee the `developer's guide`_ for more information.\n\n.. _developer's guide: https://devguide.python.org/devcycle/\n\"\"\",\n    \"typing\": \"\"\"\\\nMany recent PEPs propose changes to Python's static type system\nor otherwise relate to type annotations.\nThey are listed here for reference.\n\"\"\"\n}\n", "path": "pep_sphinx_extensions/pep_zero_generator/constants.py"}], "after_files": [{"content": "\"\"\"Holds type and status constants for PEP 0 generation.\"\"\"\n\nSTATUS_ACCEPTED = \"Accepted\"\nSTATUS_ACTIVE = \"Active\"\nSTATUS_DEFERRED = \"Deferred\"\nSTATUS_DRAFT = \"Draft\"\nSTATUS_FINAL = \"Final\"\nSTATUS_PROVISIONAL = \"Provisional\"\nSTATUS_REJECTED = \"Rejected\"\nSTATUS_SUPERSEDED = \"Superseded\"\nSTATUS_WITHDRAWN = \"Withdrawn\"\n\n# Valid values for the Status header.\nSTATUS_VALUES = {\n    STATUS_ACCEPTED, STATUS_PROVISIONAL, STATUS_REJECTED, STATUS_WITHDRAWN,\n    STATUS_DEFERRED, STATUS_FINAL, STATUS_ACTIVE, STATUS_DRAFT, STATUS_SUPERSEDED,\n}\n# Map of invalid/special statuses to their valid counterparts\nSPECIAL_STATUSES = {\n    \"April Fool!\": STATUS_REJECTED,  # See PEP 401 :)\n}\n# Draft PEPs have no status displayed, Active shares a key with Accepted\nHIDE_STATUS = {STATUS_DRAFT, STATUS_ACTIVE}\n# Dead PEP statuses\nDEAD_STATUSES = {STATUS_REJECTED, STATUS_WITHDRAWN, STATUS_SUPERSEDED}\n\nTYPE_INFO = \"Informational\"\nTYPE_PROCESS = \"Process\"\nTYPE_STANDARDS = \"Standards Track\"\n\n# Valid values for the Type header.\nTYPE_VALUES = {TYPE_STANDARDS, TYPE_INFO, TYPE_PROCESS}\n# Active PEPs can only be for Informational or Process PEPs.\nACTIVE_ALLOWED = {TYPE_PROCESS, TYPE_INFO}\n\n# map of topic -> additional description\nSUBINDICES_BY_TOPIC = {\n    \"packaging\": \"\"\"\\\nPackaging PEPs follow the `PyPA specification update process`_.\nThey are used to propose major additions or changes to the PyPA specifications.\nThe canonical, up-to-date packaging specifications can be found on the\n`Python Packaging Authority`_ (PyPA) `specifications`_ page.\n\n.. _Python Packaging Authority: https://www.pypa.io/\n.. _specifications: https://packaging.python.org/en/latest/specifications/\n.. _PyPA specification update process: https://www.pypa.io/en/latest/specifications/#specification-update-process\n\"\"\",\n    \"release\": \"\"\"\\\nA PEP is written to specify the release cycle for each feature release of Python.\nSee the `developer's guide`_ for more information.\n\n.. _developer's guide: https://devguide.python.org/devcycle/\n\"\"\",\n    \"typing\": \"\"\"\\\nMany recent PEPs propose changes to Python's static type system\nor otherwise relate to type annotations.\nThey are listed here for reference.\n\"\"\"\n}\n", "path": "pep_sphinx_extensions/pep_zero_generator/constants.py"}]}