Rename CEPs to 0000 based

.github/CODEOWNERS

@@ -1 +1 @@
-* conda/conda-core
+* conda/steering-council

.pre-commit-config.yaml

@@ -0,0 +1,24 @@
+# disable autofixing PRs, commenting "pre-commit.ci autofix" on a pull request triggers a autofix
+ci:
+  autofix_prs: false
+# generally speaking we ignore all vendored code as well as tests data
+exclude: |
+  (?x)^(
+    tests/data/.* |
+    conda_libmamba_solver/mamba_utils\.py
+  )$
+repos:
+  # generic verification and formatting
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v5.0.0
+    hooks:
+      # standard end of line/end of file cleanup
+      - id: mixed-line-ending
+      - id: end-of-file-fixer
+      - id: trailing-whitespace
+      - id: check-merge-conflict
+  - repo: meta
+    # see https://pre-commit.com/#meta-hooks
+    hooks:
+      - id: check-hooks-apply
+      - id: check-useless-excludes

README.md

@@ -10,23 +10,24 @@ for conda's implementation, all major changes should be submitted as
 
 | CEP | Title |
 | --- | ------- |
-| [1](cep-1.md) | CEP Purpose and Guidelines  |
-| [2](cep-2.md) | Add plugin architecture to conda |
-| [3](cep-3.md) | Using the Mamba solver in conda |
-| [4](cep-4.md) | Implement initial conda plugin mechanism |
-| 5 | Does not exist |
-| [6](cep-6.md) | Add Channel Notices to conda
-| 7 | Does not exist |
-| [8](cep-8.md) | Conda Release Schedule |
-| [9](cep-9.md) | Conda Deprecation Schedule |
-| [10](cep-10.md) | Conda Version Support |
-| [11](cep-11.md) | Define the menuinst standard |
-| [12](cep-12.md) | Serving run_exports metadata in conda channels |
-| [13](cep-13.md) | A new recipe format - part 1 |
-| [14](cep-14.md) | A new recipe format – part 2 - the allowed keys & values |
-| [15](cep-15.md) | Hosting repodata.json and packages separately by adding a base_url property. |
-| [16](cep-16.md) | Sharded Repodata |
-| [17](cep-17.md) | Optional python site-packages path in repodata |
+| [0000](cep-0000.md) | CEP template  |
+| [0001](cep-0001.md) | CEP Purpose and Guidelines  |
+| [0002](cep-0002.md) | Add plugin architecture to conda |
+| [0003](cep-0003.md) | Using the Mamba solver in conda |
+| [0004](cep-0004.md) | Implement initial conda plugin mechanism |
+| 0005 | _Does not exist_ |
+| [0006](cep-0006.md) | Add Channel Notices to conda
+| 0007 | _Does not exist_ |
+| [0008](cep-0008.md) | Conda Release Schedule |
+| [0009](cep-0009.md) | Conda Deprecation Schedule |
+| [0010](cep-0010.md) | Conda Version Support |
+| [0011](cep-0011.md) | Define the menuinst standard |
+| [0012](cep-0012.md) | Serving run_exports metadata in conda channels |
+| [0013](cep-0013.md) | A new recipe format - part 1 |
+| [0014](cep-0014.md) | A new recipe format – part 2 - the allowed keys & values |
+| [0015](cep-0015.md) | Hosting repodata.json and packages separately by adding a base_url property. |
+| [0016](cep-0016.md) | Sharded Repodata |
+| [0017](cep-0017.md) | Optional python site-packages path in repodata |
 
 ## References
 
@@ -39,9 +40,9 @@ Community members are encouraged to author a CEP to suggest changes *before*
 any code is written to allow for the community to discuss the proposed changes.
 
 The formal process by which CEPs should be authored and how they are reviewed
-and resolved is specified in [CEP 1](https://github.com/conda/ceps/blob/main/cep-1.md).
+and resolved is specified in [CEP-1](https://github.com/conda/ceps/blob/main/cep-0001.md).
 
-A template for new CEPs is given in [CEP 0](https://github.com/conda/ceps/blob/main/cep-0.md).
+A template for new CEPs is given in [CEP-0](https://github.com/conda/ceps/blob/main/cep-0000.md).
 
 ## Conda capitalization standards
 

cep-1.md → cep-0001.md

@@ -55,7 +55,7 @@ or as part of a conda community meeting, is the best way to go about this.
 
 Once the champion has asked the conda community whether an idea
 has any chance of acceptance, a draft CEP should be written following the
-template in [CEP 0](cep-0.md) and described below.
+template in [CEP 0](cep-0000.md) and described below.
 
 While working on the CEP prior to submission, please set its status to *draft*.
 

cep-4.md → cep-0004.md

@@ -16,7 +16,7 @@ In order to enable customization and extra features that are compatible with and
 
 A plugin mechanism in `conda` would provide many benefits, including (but not limited to) the coverage of underserved use cases, the added ability to extend `conda` internals via official APIs, as well as lowering the barrier of entry for contributions from other stakeholders in the `conda` community and ecosystem.
 
-The [initial proposal to add this plugin architecture](https://github.com/conda-incubator/ceps/blob/main/cep-2.md) has been [officially approved](https://github.com/conda-incubator/ceps/issues/23); this current CEP will discuss the specific way that the plugin mechanism will actually be implemented.
+The [initial proposal to add this plugin architecture](https://github.com/conda-incubator/ceps/blob/main/cep-0002.md) has been [officially approved](https://github.com/conda-incubator/ceps/issues/23); this current CEP will discuss the specific way that the plugin mechanism will actually be implemented.
 
 ## Specification
 
@@ -130,7 +130,7 @@ It should be noted that a request for change was recorded in the pull request ab
 ## Reference
 
 - [`pluggy` Documentation](https://pluggy.readthedocs.io/en/stable/index.html)
-- [CEP 2: "Add plugin architecture to conda"](https://github.com/conda-incubator/ceps/blob/main/cep-2.md)
+- [CEP 2: "Add plugin architecture to conda"](https://github.com/conda-incubator/ceps/blob/main/cep-0002.md)
 - [`conda` Issue #11112: Introduce a Plugin System](https://github.com/conda/conda/issues/11112)
 
 ## Copyright

cep-6.md → cep-0006.md

@@ -11,9 +11,9 @@
 
 ## Abstract
 
-In order to facilitate better communication between users of `conda` and channel owners, we want to 
+In order to facilitate better communication between users of `conda` and channel owners, we want to
 implement a notification feature.
-Specifically, this feature will give channel owners the ability to send users a small message (about the size 
+Specifically, this feature will give channel owners the ability to send users a small message (about the size
 of a single Twitter post). How often this message displays will be set by channel owners
 and will be displayed for each channel a user is actively using (i.e. everything under "channels" in a
 user's `.condarc`).
@@ -66,12 +66,12 @@ Channel "defaults" has the following notices:
   [info] -- Tue May 10 11:50:34 2022
   This is a test message. It is not very long, and could have a link to a longer post:
   https://example.com/short-link
-  
+
 ```
 
 ### How else can our users access this message?
 
-Additionally, because our users may wish to see this message on demand, we will add a new sub-command called `notices`. 
+Additionally, because our users may wish to see this message on demand, we will add a new sub-command called `notices`.
 The following are a couple examples to show exactly how it would function:
 
 **Basic usage:** grabs notices for all current channels:
@@ -105,8 +105,8 @@ Channel "defaults" has the following notices:
 
 ### What file format will this message have, and what will it contain?
 
-The notification message will be in the JSON file format. This will allow us to not only store the message itself but 
-also metadata about the message, including information about how often the client should display the message (more on 
+The notification message will be in the JSON file format. This will allow us to not only store the message itself but
+also metadata about the message, including information about how often the client should display the message (more on
 this in the next section).
 
 Here's an example of the `notices.json` file which will be stored in the root of the channel directory structure.
@@ -137,7 +137,7 @@ Detailed overview of the JSON fields:
 
 ### How often will these messages appear?
 
-How often these messages appear will be configurable by the channel owners and the client. This will be accomplished by 
+How often these messages appear will be configurable by the channel owners and the client. This will be accomplished by
 the `expires_at` field in the `notices.json` file itself. When a message has expired, it will trigger a refresh from the
 server at which point it will show new messages if there are any.
 
@@ -155,7 +155,7 @@ The motivation for this CEP came about as channel owners (Anaconda specifically)
 users of their channels. These messages may contain specific notices for particular users (e.g. identified by
 IP address) or general messages for the wider audience of a particular channel.
 
-Additionally, this new notification space can also provide a place for us to relocate `conda update conda` reminders 
+Additionally, this new notification space can also provide a place for us to relocate `conda update conda` reminders
 to a more visible spot (at the end of command output versus in the middle of the output). On top of this, other channels
 can use these notices as a way to share news with their users or requests for help in maintaining their channels.
 
@@ -170,7 +170,7 @@ channels may choose to dynamically serve this JSON file and this specification a
 
 The other consideration was keeping these messages to a minimum for our users and allowing them to easily disable
 these messages if they do not want to see them while running commands such as "install" or "create". Although
-we feel these messages are important for users to see, we also do not want to clutter their terminal output. 
+we feel these messages are important for users to see, we also do not want to clutter their terminal output.
 Ultimately, this is why we are choosing to turn this on by default but are also providing a way to disable it.
 
 
@@ -184,14 +184,14 @@ We do not expect any backwards compatibility issues for this new feature.
 - **Show notices at the beginning of environment activation:** This was deemed too intrusive/annoying.
 - **Show notices at the beginning of command output:** Users may miss this if placed here, especially for commands
   with lots of output
-- **Message in an HTTP header when retrieving any file from the repository:** This would be a better option for some kinds 
+- **Message in an HTTP header when retrieving any file from the repository:** This would be a better option for some kinds
   of messages, like download rate limiting or other blocks due to abuse, since it could be turned on by a rule in a CDN.
-  However, this use case is probably better addressed by having a standard way for `conda` to display errors on the 
+  However, this use case is probably better addressed by having a standard way for `conda` to display errors on the
   console from HTTP status codes like 429 (Too Many Requests) and 403 (Forbidden). Additionally, serving custom headers
-  is challenging unless the repository owner has more control over the web server than is usually given by services 
+  is challenging unless the repository owner has more control over the web server than is usually given by services
   like Github Pages.
 - **Add notices to the repodata.json file:** The repodata.json file is already being fetched, so adding some
-  notices would reduce the number of requests. However, the repodata.json file is way too big already, so it 
+  notices would reduce the number of requests. However, the repodata.json file is way too big already, so it
   would require clients to download a fairly large file before even being able to show the notification.
 - **Create a generic metadata.json file containing a notices key:** This could be appealing for
   creating a space for other kinds of channel metadata, but in order to keep things as simple as possible at the moment

cep-9.md → cep-0009.md

@@ -9,7 +9,7 @@
 </table>
 
 <!-- links -->
-[cep8]: https://github.com/conda-incubator/ceps/blob/main/cep-8.md
+[cep8]: https://github.com/conda-incubator/ceps/blob/main/cep-0008.md
 [django]: https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy
 [voting]: https://github.com/conda-incubator/governance#enhancement-proposal-approval
 

cep-10.md → cep-0010.md

@@ -10,7 +10,7 @@
 
 ## Abstract
 
-This CEP introduces an official version support policy to promote transparency and certainty 
+This CEP introduces an official version support policy to promote transparency and certainty
 about which versions of conda are supported. The policy itself states that only the latest
 released version of conda will be supported. Instead of patching previous releases, maintainers
 will only focus their efforts on new and current releases. The implications of
@@ -21,7 +21,7 @@ this and how this looks will be outlined below.
 The latest version of conda will be the only officially supported version of conda. This relates
 only to the conda project itself (i.e. conda-build is not included). This means that the only
 time patch releases will be made are soon after a release goes out. For example, if a
-bug is identified soon after releasing conda `23.11.0` and fixed, a subsequent `23.11.1` 
+bug is identified soon after releasing conda `23.11.0` and fixed, a subsequent `23.11.1`
 release will be made. Patch releases for conda versions older than the current version
 will not be made.
 
@@ -41,15 +41,15 @@ a particular version of conda will be supported. We do not expect our users to
 always be running the latest version of conda, but we also do not want to give
 users the impression that every version of conda will be supported indefinitely.
 Therefore, we felt it necessary to outline with this CEP exactly which versions
-will be supported and how. This not only helps set expectations for our users but 
-also eases our development efforts knowing we no longer have to support older versions 
+will be supported and how. This not only helps set expectations for our users but
+also eases our development efforts knowing we no longer have to support older versions
 of conda.
 
 ## Rationale
 
 For many projects (more information here: https://endoflife.date), either
 the latest version is supported or the projects have a sliding window of time
-for their supported versions. This window is a guarantee saying that the 
+for their supported versions. This window is a guarantee saying that the
 version in question will be supported for a specific amount of time. For most who
 use a version window, they further specify the types of fixes a version will receive
 as it ages.
@@ -91,4 +91,4 @@ Helpful websites and articles:
 All CEPs are explicitly [CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/).
 
 
-[deprecation-schedule]: https://github.com/conda-incubator/ceps/blob/main/cep-9.md
+[deprecation-schedule]: https://github.com/conda-incubator/ceps/blob/main/cep-0009.md

cep-11.md → cep-0011.md

@@ -55,7 +55,7 @@ simplified overview of all possible keys and their default values:
       "platforms": {
         # To create the menu item for a fiven platform, the key must be present in this
         # dictionary. Presence is enough; the value can just be the empty dictionary: {}.
-        "linux": {  
+        "linux": {
           # See XDG Desktop standard for details
           # https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
           "Categories": None,
@@ -98,7 +98,7 @@ simplified overview of all possible keys and their default values:
           #: see https://developer.apple.com/documentation/bundleresources/entitlements
           "entitlements": None,
           #: symlink a file (usually the executable in 'command') into the .app directory
-          "link_in_bundle": None, 
+          "link_in_bundle": None,
           #: shell logic that will run when an Apple event is received
           "event_handler": None,
         },
@@ -141,9 +141,9 @@ Placeholder | Value
 `HOME` | Path to the user directory (`~`).
 `ICON_EXT` | Extension of the icon file expected by each platform. `png` in Linux, `icns` in macOS, and `ico` in Windows. Note the dot is _not_ included.
 **macOS-only** |
-`PYTHONAPP` | Path to the `python` executable installed in `PREFIX`, assuming the `python.app` conda package is installed. Equivalent to `{{ PREFIX }}/python.app/Contents/MacOS/python`. 
-**Windows-only** | 
-`SCRIPTS_DIR` | Path to the `Scripts` directory in `PREFIX`. 
+`PYTHONAPP` | Path to the `python` executable installed in `PREFIX`, assuming the `python.app` conda package is installed. Equivalent to `{{ PREFIX }}/python.app/Contents/MacOS/python`.
+**Windows-only** |
+`SCRIPTS_DIR` | Path to the `Scripts` directory in `PREFIX`.
 `BASE_PYTHONW` | Path to the `pythonw.exe` executable in `BASE_PREFIX`.
 `PYTHONW` | Path to the `pythonw.exe` executable in `PREFIX`.
 
@@ -190,12 +190,12 @@ resources (XML files on Linux, Registry on Windows), these MUST be undone too.
 ## CLI interface
 
 The implementor CLI is _not_ defined in this document. However, the integrations with `constructor`
-SHOULD be standardized if they are going to be kept in use. 
+SHOULD be standardized if they are going to be kept in use.
 
 The proposed CLI (inspired by what's already in use to introduce minimal changes) is:
 
 ```shell
-${IMPLEMENTOR} constructor --prefix ${PREFIX} [--base-prefix ${BASE_PREFIX}] [--mode user|system] [--make-menus | --rm-menus] [pkg-name ...] 
+${IMPLEMENTOR} constructor --prefix ${PREFIX} [--base-prefix ${BASE_PREFIX}] [--mode user|system] [--make-menus | --rm-menus] [pkg-name ...]
 ```
 
 - `--make-menus` will create the menu items for the JSON files found in `$PREFIX/Menu`.
@@ -365,7 +365,7 @@ implemented. Per-platform options are allowed but only when strictly necessary.
 - A binary launcher is required for correct system integration (see reasons
   [`conda/menuinst#123`](https://github.com/conda/menuinst/issues/123)). This is placed at
   `<NAME>.app/Contents/MacOS/<NAME>`. The proposed launcher simply guesses its own location to find
-  the `*-script` file, which is spawned in a subprocess. 
+  the `*-script` file, which is spawned in a subprocess.
 - In some cases, if an external binary is required, it needs to be symlinked into the `.app`
   directory to ensure keyboard integrations work (see
   [`conda/menuinst#122`](https://github.com/conda/menuinst/issues/122)).

cep-12.md → cep-0012.md

@@ -2,7 +2,7 @@
 <tr><td> Title </td><td> Serving run_exports metadata in conda channels </td>
 <tr><td> Status </td><td> Accepted </td></tr>
 <tr><td> Author(s) </td>
-<td> 
+<td>
     Jaime Rodríguez-Guerra &lt;[email protected]&gt;
 </td></tr>
 <tr><td> Created </td><td> May 4, 2023</td></tr>
@@ -27,11 +27,11 @@ Since `conda-index` already processes the package metadata to generate `repodata
 
 ## Precedence and role in the pinning resolution process
 
-This file is not meant to replace the `run_exports` metadata already present in the package archives. It merely presents that information in a more convenient way. 
+This file is not meant to replace the `run_exports` metadata already present in the package archives. It merely presents that information in a more convenient way.
 `conda-build`-like clients are free to use either the `run_exports` metadata in the archives or the one in `run_exports.json`, since they MUST be equivalent.
 Special keys like `pin_run_as_build` MUST keep their behavior, since `run_exports.json` does not add a new level of precedence in the pinning resolution process. Again, it's an equivalent source for information already present in the archives.
 
-This means that `run_exports.json` MUST NOT be patched (like it is done with `repodata.json`). It MUST always reflect the metadata present in the archives. 
+This means that `run_exports.json` MUST NOT be patched (like it is done with `repodata.json`). It MUST always reflect the metadata present in the archives.
 
 > Note this only applies to the served `run_exports.json` file. It does not try to regulate what
 > `conda-build`-like tools can do at environment creation time. They might need to apply
@@ -57,7 +57,7 @@ Each `run_exports` metadata `dict` can contain the following fields; each field
 - `noarch`
 
 ```json
-{   
+{
     "info": {
         "platform": "string",
         "arch": "string",