|
| 1 | +PEP: 685 |
| 2 | +Title: Comparison of extra names for optional distribution dependencies |
| 3 | +Author: Brett Cannon < [email protected]> |
| 4 | +Discussions-To: https://discuss.python.org/t/pep-685-comparison-of-extra-names-for-optional-distribution-dependencies/14141 |
| 5 | +Status: Draft |
| 6 | +Type: Standards Track |
| 7 | +Content-Type: text/x-rst |
| 8 | +Created: 08-Mar-2022 |
| 9 | +Post-History: 08-Mar-2022 |
| 10 | + |
| 11 | + |
| 12 | +Abstract |
| 13 | +======== |
| 14 | + |
| 15 | +This PEP specifies how to normalize `distribution _extra_ <Provides-Extra_>`_ |
| 16 | +names when performing comparisons. |
| 17 | +This prevents tools from either failing to find an extra name or |
| 18 | +accidentally matching against an unexpected name. |
| 19 | + |
| 20 | + |
| 21 | +Motivation |
| 22 | +========== |
| 23 | + |
| 24 | +The `Provides-Extra`_ core metadata specification says that an extra's |
| 25 | +name "must be a valid Python identifier". |
| 26 | +:pep:`508` says that the value of an ``extra`` marker may contain a |
| 27 | +letter, digit, or any one of ``.``, ``-``, or ``_`` after the initial character. |
| 28 | +Otherwise there is no other specification at https://packaging.python.org |
| 29 | +which outlines how extra names should be written or normalization for comparison. |
| 30 | +Due to the amount of packaging-related code out there, |
| 31 | +it is important to evaluate current practices by the community and |
| 32 | +standardize on a practice that doesn't break most code while being |
| 33 | +something tool authors can agree to following. |
| 34 | + |
| 35 | +The issue of no standard was brought forward via the discussion at |
| 36 | +https://discuss.python.org/t/what-extras-names-are-treated-as-equal-and-why/7614 |
| 37 | +where the extra ``adhoc-ssl`` was not considered equal to the name |
| 38 | +``adhoc_ssl`` by pip. |
| 39 | + |
| 40 | + |
| 41 | +Rationale |
| 42 | +========= |
| 43 | + |
| 44 | +:pep:`503` specifies how to normalize distribution names: |
| 45 | +``re.sub(r"[-_.]+", "-", name).lower()``. |
| 46 | +This collapses any run of the substitution character down to a single |
| 47 | +character, |
| 48 | +e.g. ``---`` gets collapsed down to ``-``. |
| 49 | +This does not produce a valid Python identifier as specified by the |
| 50 | +core metadata specification for extra names. |
| 51 | + |
| 52 | +`Setuptools does normalization <https://github.com/pypa/setuptools/blob/b2f7b8f92725c63b164d5776f85e67cc560def4e/pkg_resources/__init__.py#L1324-L1330>`__ |
| 53 | +via ``re.sub('[^A-Za-z0-9.-]+', '_', name).lower()``. |
| 54 | +The use of an underscore/``_`` differs from PEP 503's use of a |
| 55 | +hyphen/``-``. |
| 56 | +Runs of characters, unlike PEP 503, do **not** get collapsed, |
| 57 | +e.g. ``___`` stays the same. |
| 58 | + |
| 59 | +For pip, its |
| 60 | +"extra normalisaton behaviour is quite convoluted and eratic", |
| 61 | +and so its use is not considered. |
| 62 | + |
| 63 | + |
| 64 | +Specification |
| 65 | +============= |
| 66 | + |
| 67 | +[Describe the syntax and semantics of any new language feature.] |
| 68 | + |
| 69 | +When comparing extra names, tools MUST normalize the names being compared |
| 70 | +using the equivalent semantics of |
| 71 | +``re.sub('[^A-Za-z0-9.-]+', '_', name).lower()``. |
| 72 | +This normalizes any extra name previously allowed by :pep:`508` in a |
| 73 | +consistent fashion with setuptools. |
| 74 | + |
| 75 | +For tools writing `core metadata`_, |
| 76 | +they MUST write out extra names in their normalized form. |
| 77 | +This applies to the ``Provides-Extra`` field and the ``Provides-Dist`` |
| 78 | +field both when specifying extras for a distribution as well as the |
| 79 | +``extra`` marker. |
| 80 | +This will also help enforce the curren requirement from the core |
| 81 | +metadata specification that extra names be valid Python identifiers. |
| 82 | + |
| 83 | +Tools generating metadata MUST also raise an error if a user specified |
| 84 | +two or more extra names which would normalize to the same name. |
| 85 | + |
| 86 | + |
| 87 | +Backwards Compatibility |
| 88 | +======================= |
| 89 | + |
| 90 | +Older distributions which contain conflicting names when normalized |
| 91 | +will no longer have all of their extra names made available to users |
| 92 | +as independent options, but instead as a single extra. |
| 93 | +It is hoped that relying on setuptools' algorithm for normalization |
| 94 | +will minimize the breakage from this. |
| 95 | + |
| 96 | +As distributions make new releases using tools which implement this |
| 97 | +PEP, |
| 98 | +the backwards-compatibility issues will become less of a concern. |
| 99 | + |
| 100 | + |
| 101 | +Security Implications |
| 102 | +===================== |
| 103 | + |
| 104 | +It is possible that a distribution has conflicting extra names and a |
| 105 | +tool ends up installing distributions that somehow weaken the security |
| 106 | +of the system. |
| 107 | +This is only hypothetical and if it were to occur it would probably be |
| 108 | +more of a security concern for the distributions involved more than |
| 109 | +the distribution that pulled them in together. |
| 110 | + |
| 111 | + |
| 112 | +How to Teach This |
| 113 | +================= |
| 114 | + |
| 115 | +This should be transparent to users on a day-to-day basis. |
| 116 | +It will be up to tools to educate/stop users when they select extra |
| 117 | +names which conflict. |
| 118 | + |
| 119 | + |
| 120 | +Reference Implementation |
| 121 | +======================== |
| 122 | + |
| 123 | +No reference implementation is provided, |
| 124 | +but the expectation is the `packaging project`_ will provide a |
| 125 | +function in its ``packaging.utils`` that will implement extra name |
| 126 | +normalization. |
| 127 | +It will also implement extra name comparisons appropriately. |
| 128 | +Finally, if the project ever gains the ability to write out metadata, |
| 129 | +it will also implement this PEP. |
| 130 | + |
| 131 | + |
| 132 | +Rejected Ideas |
| 133 | +============== |
| 134 | + |
| 135 | +Normalize names according to PEP 503 |
| 136 | +------------------------------------ |
| 137 | + |
| 138 | +For backwards-compatibility concerns, |
| 139 | +it was decided not to follow :pep:`503` and how it normalizes |
| 140 | +distribution names. |
| 141 | + |
| 142 | + |
| 143 | +Open Issues |
| 144 | +=========== |
| 145 | + |
| 146 | +N/A |
| 147 | + |
| 148 | + |
| 149 | +Copyright |
| 150 | +========= |
| 151 | + |
| 152 | +This document is placed in the public domain or under the |
| 153 | +CC0-1.0-Universal license, whichever is more permissive. |
| 154 | + |
| 155 | + |
| 156 | +.. _core metadata: https://packaging.python.org/en/latest/specifications/core-metadata/ |
| 157 | +.. _packaging project: https://packaging.pypa.io |
| 158 | +.. _Provides-Extra: https://packaging.python.org/en/latest/specifications/core-metadata/#provides-extra-multiple-use |
| 159 | + |
0 commit comments