You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Developers are free to use this repository's `README.md` to familiarize with the CLI and save time from having to install any dependencies, but development within a Conda environment is heavily recommended regardless
4
-
* Gain access to the repository with `git clone --recursive git@github.com:ilaflott/fremorizer.git` or your fork's link (recommended) and an SSH RSA key
5
-
- Once inside the repository, developers can test local changes by running a `pip install .` inside of the root directory after activating a virtual environment, installing the fremorizer package locally with the newest local changes on top of the installed Conda fremorizer dependencies. the `-e` flag can be used for an editable installation
4
+
* Gain access to the repository with `git clone --recursive git@github.com:NOAA-GFDL/fremor.git` or your fork's link (recommended) and an SSH RSA key
5
+
- Once inside the repository, developers can test local changes by running a `pip install .` inside of the root directory after activating a virtual environment, installing the fremor package locally with the newest local changes on top of the installed Conda fremor dependencies. the `-e` flag can be used for an editable installation
6
6
- Test as a normal user would use the CLI
7
7
* Create a GitHub issue to reflect your contribution's background and reference it with Git commits
8
8
@@ -13,10 +13,10 @@ With few exceptions, pull requests always require an issue.
13
13
### **Adding Tools From Other Repositories**
14
14
15
15
* Currently, the solution to this task is to approach it using Conda packages. The tool that is being added must reside within a repository that contains a meta.yaml that includes Conda dependencies like the one in this repository and ideally a setup.py (may be subject to change due to deprecation) that may include any potentially needed pip dependencies
16
-
- Once published as a Conda package, ideally on the [NOAA-GFDL channel](https://anaconda.org/NOAA-GFDL), an addition can be made to the "run" section under the "requirements" category in the meta.yaml of the fremorizer following the syntax `channel::package`
17
-
- On pushes to the main branch, the [package](https://anaconda.org/ilaflott/fremorizer) will automatically be updated using the workflow file
16
+
- Once published as a Conda package, ideally on the [NOAA-GFDL channel](https://anaconda.org/NOAA-GFDL), an addition can be made to the "run" section under the "requirements" category in the meta.yaml of the fremor following the syntax `channel::package`
17
+
- On pushes to the main branch, the [package](https://anaconda.org/NOAA-GFDL/fremor) will automatically be updated using the workflow file
18
18
19
19
### **MANIFEST.in**
20
20
21
-
* In the case where non-python files like templates, examples, and outputs are to be included in the fremorizer package, MANIFEST.in can provide the solution. Ensure that the file exists within the correct folder, and add a line to the MANIFEST.in following [this syntax](https://setuptools.pypa.io/en/latest/userguide/miscellaneous.html)
21
+
* In the case where non-python files like templates, examples, and outputs are to be included in the fremor package, MANIFEST.in can provide the solution. Ensure that the file exists within the correct folder, and add a line to the MANIFEST.in following [this syntax](https://setuptools.pypa.io/en/latest/userguide/miscellaneous.html)
AI was heavily used in the creation of this repository, primarily `github`'s `copilot` with `Claude` (`opus4.6``sonnet4.6`, and `haiku`), and `Gemini` and `Chat-GPT` models to a lesser extent, in agent mode. `Claude` and `Codex` agents have also contributed.
@@ -57,59 +57,59 @@ For development and testing, `pylint`, `pytest`, and `pytest-cov` are all highly
57
57
If you're trying to gain access to `fremor` functionality as quickly as possible:
58
58
```bash
59
59
# the current post-release in main
60
-
module load fremorizer/test
60
+
module load fremor/test
61
61
62
-
# a tagged version of fremorizer, post-releases will never be named modules
63
-
module load fremorizer/X.Y.Z
62
+
# a tagged version of fremor, post-releases will never be named modules
63
+
module load fremor/X.Y.Z
64
64
```
65
65
66
66
67
67
### via `conda`
68
-
If you have a path to a `fremorizer` environment you can activate it like so:
68
+
If you have a path to a `fremor` environment you can activate it like so:
The `wcrp_compliance_check` workflow validates CMORized NetCDF outputs against WCRP project
171
171
specifications using [cc-plugin-wcrp](https://github.com/ESGF/cc-plugin-wcrp), a plugin for
@@ -193,16 +193,16 @@ Apache License 2.0 — see [LICENSE.md](LICENSE.md)
193
193
194
194
195
195
## Releases and Versioning
196
-
`fremorizer` uses a post-release scheme to identify development beyond the latest tagged version and tie the current `main` branch to a
196
+
`fremor` uses a post-release scheme to identify development beyond the latest tagged version and tie the current `main` branch to a
197
197
`conda` package versioned as `develop`. To avoid confusion with `fre-workflows` and `fre-cli`, which often demand that the version tags
198
-
match, `fremorizer`'s version format is `X.Y.Z[.post]`.
198
+
match, `fremor`'s version format is `X.Y.Z[.post]`.
199
199
200
200
201
201
### new published release procedure
202
202
To publish new release carefully follow the below procedure:
203
203
1. create a new branch off of `main`, which is already published to `conda` under `develop`/the previous tagged version + `.post`
204
-
2. edit the version number in `fremorizer/_version.py` from the current one, to the desired version tag, remove `.post`, then open a PR. edit nothing else (usually).
204
+
2. edit the version number in `fremor/_version.py` from the current one, to the desired version tag, remove `.post`, then open a PR. edit nothing else (usually).
205
205
3. confirm the branch is functional by letting workflows finish, if you see green checks only, proceed. otherwise, stop and debug.
206
206
4. draft a new release pointing to the PR branch, click release. the publishing workflow should trigger and finish, and you should see the `X.Y.Z` version in the conda channel.
207
207
5.*releases in this repository are immutable*, **so even if the release workflow fails, breathe and move on to the next step.**
208
-
6. edit the version number in `fremorizer/_version.py` to `X.Y.Z.post`, and merge the PR to main workflow steps passed. **`publish_conda`** will trigger again and upload what is in `main` under the `conda` version `develop` and `pip` version `X.Y.Z.post`
208
+
6. edit the version number in `fremor/_version.py` to `X.Y.Z.post`, and merge the PR to main workflow steps passed. **`publish_conda`** will trigger again and upload what is in `main` under the `conda` version `develop` and `pip` version `X.Y.Z.post`
0 commit comments