From 7c3d9a2420258110efb5120a176fb50a0c505b0a Mon Sep 17 00:00:00 2001
From: "github-actions[bot]" <github-actions[bot]@users.noreply.github.com>
Date: Tue, 12 Mar 2024 17:54:17 +0000
Subject: [PATCH] Deployed 5c1cb84 with MkDocs version: 1.5.3

---
 index.html               |   2 +-
 search/search_index.json |   2 +-
 setup/index.html         |   3 +++
 sitemap.xml.gz           | Bin 127 -> 127 bytes
 workflow/index.html      |   9 ++++++++-
 5 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/index.html b/index.html
index 0f6599c..60c421d 100644
--- a/index.html
+++ b/index.html
@@ -180,5 +180,5 @@ <h4 class="modal-title" id="keyboardModalLabel">Keyboard Shortcuts</h4>
 
 <!--
 MkDocs version : 1.5.3
-Build Date UTC : 2024-03-12 16:09:55.418909+00:00
+Build Date UTC : 2024-03-12 17:54:17.836327+00:00
 -->
diff --git a/search/search_index.json b/search/search_index.json
index 4c51e70..793985a 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"IceDyno Documentation \u00b6 Short-Term Forecasting of Sea-Ice Edge Boundaries in the Arctic \u00b6 Authors: Ruchi Asthana, Julieanna Bacon, Brendon Gory, Matthew Thanos, Soolu Thomas Welcome to the project! This is a data science Master's capstone through Harvard University's Extension School, in collaboration with NOAA.","title":"Home"},{"location":"#icedyno-documentation","text":"","title":"IceDyno Documentation"},{"location":"#short-term-forecasting-of-sea-ice-edge-boundaries-in-the-arctic","text":"Authors: Ruchi Asthana, Julieanna Bacon, Brendon Gory, Matthew Thanos, Soolu Thomas Welcome to the project! This is a data science Master's capstone through Harvard University's Extension School, in collaboration with NOAA.","title":"Short-Term Forecasting of Sea-Ice Edge Boundaries in the Arctic"},{"location":"GH-cheatsheet/","text":"GitHub Cheatsheet \u00b6 Here's a quick cheatsheet on getting started with a GitHub project, if you are new to GitHub. Before we start, anything that is within the angle brackets ( < or > ) should be replaced as a whole. For example: <your-username> should be replaced to something like SooluThomas Table of contents \u00b6 Set up SSH keys Clone repository Create feature branches Check username and email in your local git Add, commit and push changes to feature branch Create Pull Request Pull changes from the main to feature branch Set up SSH keys \u00b6 Most of GitHub's documentation is pretty good. So pointing to GH docs for 1. Check for existing SSH key 2. Generate new SSH key > Its easier to just follow the 3 steps mentioned under \"Generating a new SSH key\" section. 3. Add a new SSH key 4. Test your SSH connection Clone repository \u00b6 Once SSH keys are set up, in your terminal move to the which ever directory you want to have the local repo copy to live using the command cd Documents/<your-folder-path>/Capstone Then clone the repo using the command git clone git@github.com:NOAA-HES-Capstone/icedyno.git cd icedyno (Tip: the link was obtained from the repo -> green button called \"Code\" on top right of the repo -> SSH) Once this is done, you should be able to see the main branch (by default) locally. Create feature branches \u00b6 Create a branch using the command git checkout -b <your-initials>/<branch-name> # This command can show you which branch you are in # The * shows the current branch you are in git branch # you can use `git checkout main` to go to main branch and then # `git checkout <branch-name>` to go to different branch Check username and email in your local git \u00b6 This is an optional step but might be nice to have. This is a one-time thing to do. Run the following: git config user.name git config user.email If this is showing the correct github username and email, you are good. Otherwise, run git config user.name <your-username> git config user.email <your-registered-email> Add, commit and push changes to feature branch \u00b6 # This will show us a summary of the files changed when compared main branch git status # Add the files that were changed # It is always best to add the file names rather than to use `git add *` # so that unwanted files don't get added git add <path>/<file-name> # Commit your changes git commit -m \"Type out commit message with a one line summary briefing the changes\" # TIP: if you want to add more descriptive commit add -m \"descriptive message\" # after the one line summary message # [ALWAYS] Push commit to your branch git push origin <your-initials>/<branch-name> Create Pull Request \u00b6 If you are pushing from a branch for the first time , the first commit will show a link that point to creating a pull request (PR) directly. It should be something like Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 1.36 KiB | 1.36 MiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'soo/add-gh-cheatsheat' on GitHub by visiting remote: https://github.com/NOAA-HES-Capstone/icedyno/pull/new/soo/add-gh-cheatsheat remote: To github.com:NOAA-HES-Capstone/icedyno.git * [new branch] soo/add-gh-cheatsheat -> soo/add-gh-cheatsheat Another way to open a PR is going to the repo itself and find your branch name under the branch selector in the repository. After you click on it, it should have a button to create a pull request. Pull changes from the main to feature branch \u00b6 There could be cases where other PRs could be merged before ours and so we will need to pull those changes in our branch before we can merge or to make sure that our work doesn't break anything with the new changes made in the main branch. For this we can use # Fetch all the changes from remote to local git fetch # pull the changes from main to our feature branch git pull origin main If your are pulling for the first time in that repo, the might be a lot more that will be asked in the terminal and run the command for merge which is something like git config pull.rebase false Let's keep this file growing with the GitHub tips that you get know and would like to share with others.","title":"GitHub"},{"location":"GH-cheatsheet/#github-cheatsheet","text":"Here's a quick cheatsheet on getting started with a GitHub project, if you are new to GitHub. Before we start, anything that is within the angle brackets ( < or > ) should be replaced as a whole. For example: <your-username> should be replaced to something like SooluThomas","title":"GitHub Cheatsheet"},{"location":"GH-cheatsheet/#table-of-contents","text":"Set up SSH keys Clone repository Create feature branches Check username and email in your local git Add, commit and push changes to feature branch Create Pull Request Pull changes from the main to feature branch","title":"Table of contents"},{"location":"GH-cheatsheet/#set-up-ssh-keys","text":"Most of GitHub's documentation is pretty good. So pointing to GH docs for 1. Check for existing SSH key 2. Generate new SSH key > Its easier to just follow the 3 steps mentioned under \"Generating a new SSH key\" section. 3. Add a new SSH key 4. Test your SSH connection","title":"Set up SSH keys"},{"location":"GH-cheatsheet/#clone-repository","text":"Once SSH keys are set up, in your terminal move to the which ever directory you want to have the local repo copy to live using the command cd Documents/<your-folder-path>/Capstone Then clone the repo using the command git clone git@github.com:NOAA-HES-Capstone/icedyno.git cd icedyno (Tip: the link was obtained from the repo -> green button called \"Code\" on top right of the repo -> SSH) Once this is done, you should be able to see the main branch (by default) locally.","title":"Clone repository"},{"location":"GH-cheatsheet/#create-feature-branches","text":"Create a branch using the command git checkout -b <your-initials>/<branch-name> # This command can show you which branch you are in # The * shows the current branch you are in git branch # you can use `git checkout main` to go to main branch and then # `git checkout <branch-name>` to go to different branch","title":"Create feature branches"},{"location":"GH-cheatsheet/#check-username-and-email-in-your-local-git","text":"This is an optional step but might be nice to have. This is a one-time thing to do. Run the following: git config user.name git config user.email If this is showing the correct github username and email, you are good. Otherwise, run git config user.name <your-username> git config user.email <your-registered-email>","title":"Check username and email in your local git"},{"location":"GH-cheatsheet/#add-commit-and-push-changes-to-feature-branch","text":"# This will show us a summary of the files changed when compared main branch git status # Add the files that were changed # It is always best to add the file names rather than to use `git add *` # so that unwanted files don't get added git add <path>/<file-name> # Commit your changes git commit -m \"Type out commit message with a one line summary briefing the changes\" # TIP: if you want to add more descriptive commit add -m \"descriptive message\" # after the one line summary message # [ALWAYS] Push commit to your branch git push origin <your-initials>/<branch-name>","title":"Add, commit and push changes to feature branch"},{"location":"GH-cheatsheet/#create-pull-request","text":"If you are pushing from a branch for the first time , the first commit will show a link that point to creating a pull request (PR) directly. It should be something like Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 1.36 KiB | 1.36 MiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'soo/add-gh-cheatsheat' on GitHub by visiting remote: https://github.com/NOAA-HES-Capstone/icedyno/pull/new/soo/add-gh-cheatsheat remote: To github.com:NOAA-HES-Capstone/icedyno.git * [new branch] soo/add-gh-cheatsheat -> soo/add-gh-cheatsheat Another way to open a PR is going to the repo itself and find your branch name under the branch selector in the repository. After you click on it, it should have a button to create a pull request.","title":"Create Pull Request"},{"location":"GH-cheatsheet/#pull-changes-from-the-main-to-feature-branch","text":"There could be cases where other PRs could be merged before ours and so we will need to pull those changes in our branch before we can merge or to make sure that our work doesn't break anything with the new changes made in the main branch. For this we can use # Fetch all the changes from remote to local git fetch # pull the changes from main to our feature branch git pull origin main If your are pulling for the first time in that repo, the might be a lot more that will be asked in the terminal and run the command for merge which is something like git config pull.rebase false Let's keep this file growing with the GitHub tips that you get know and would like to share with others.","title":"Pull changes from the main to feature branch"},{"location":"setup/","text":"Setup \u00b6 To get started, clone the repo, checkout this branch, using Linux install pixi with: curl -fsSL https://pixi.sh/install.sh | bash For Mac, install via homebrew with brew install pixi If using windows, install pixi with: iwr -useb https://pixi.sh/install.ps1 | iex See here for more info on pixi: https://pixi.sh/. Then to install the project and its dependencies, type: pixi install You could activate the virtual environment with pixi shell (so every command uses the virtual environment until you type exit ) or prefix your commands with pixi run inside the icedyno project folder (ex: pixi run pytest ). To set up the automatic linters (that run every time you commit your work), you would run: pixi run pre-commit install Testing the set up \u00b6 If you activated the pixi environment, type pytest . If not, type pixi run pytest . You should have one dummy test that runs on that command. What does it look like when the linters and pre-commit hooks run? \u00b6 After you've installed the pre-commit hooks and have changes to commit, this is what the process will look like for committing: You have changes to commit: Commit with a descriptive message: One-time setup of the linters: Our code was not already compliant with the linters, so they \"failed\" our commit and automatically changed things about our code to become compliant: Go ahead and inspect what got modified if you'd like: Add the changes and redo your commit command: Adding new dependencies \u00b6 Just write pixi add conda_or_pip_package_name . You can add multiple dependencies at once (which is better than one at a time, pixi will have to recompute work otherwise) by adding a space between the package names. I.e. pixi add package1 package2 package3 . You'll see that the pixi.toml and pixi.lock files will change after adding your new dependencies -- make sure to add those changes in your next commit! Removing a dependency \u00b6 pixi remove package_name Documentation \u00b6 Mkdocs is the documentation engine that takes hand-written markdown files to a project website. Please read more at https://www.mkdocs.org/. Mkdocstrings is a mkdocs extension that allows autogenerated documentation to be made, by scraping type hints and documentation strings for any python modules within the project. Building and serving the documentation commands locally \u00b6 mkdocs new [dir-name] - Create a new project. mkdocs serve - Start the live-reloading docs server. mkdocs build - Build the documentation site. mkdocs -h - Print help message and exit. Documentation files layout \u00b6 mkdocs.yml # The configuration file. docs/ images/ # Folder for storing local images for documentation, including for the README.md. index.md # The documentation homepage. ... # Other markdown pages. Add a new page or subpage \u00b6 To add a new page, in mkdocs.yml add the page (or subpage) by: site_name: IceDyno Documentation nav: - Home: index.md - Setup: setup.md - New Page: newpage.md - New SubPage: newsubpage.md - ... Autogenerate documentation for an IceDyno module \u00b6 Add to a markdown file something like this: ::: icedyno.preprocess","title":"Setup"},{"location":"setup/#setup","text":"To get started, clone the repo, checkout this branch, using Linux install pixi with: curl -fsSL https://pixi.sh/install.sh | bash For Mac, install via homebrew with brew install pixi If using windows, install pixi with: iwr -useb https://pixi.sh/install.ps1 | iex See here for more info on pixi: https://pixi.sh/. Then to install the project and its dependencies, type: pixi install You could activate the virtual environment with pixi shell (so every command uses the virtual environment until you type exit ) or prefix your commands with pixi run inside the icedyno project folder (ex: pixi run pytest ). To set up the automatic linters (that run every time you commit your work), you would run: pixi run pre-commit install","title":"Setup"},{"location":"setup/#testing-the-set-up","text":"If you activated the pixi environment, type pytest . If not, type pixi run pytest . You should have one dummy test that runs on that command.","title":"Testing the set up"},{"location":"setup/#what-does-it-look-like-when-the-linters-and-pre-commit-hooks-run","text":"After you've installed the pre-commit hooks and have changes to commit, this is what the process will look like for committing: You have changes to commit: Commit with a descriptive message: One-time setup of the linters: Our code was not already compliant with the linters, so they \"failed\" our commit and automatically changed things about our code to become compliant: Go ahead and inspect what got modified if you'd like: Add the changes and redo your commit command:","title":"What does it look like when the linters and pre-commit hooks run?"},{"location":"setup/#adding-new-dependencies","text":"Just write pixi add conda_or_pip_package_name . You can add multiple dependencies at once (which is better than one at a time, pixi will have to recompute work otherwise) by adding a space between the package names. I.e. pixi add package1 package2 package3 . You'll see that the pixi.toml and pixi.lock files will change after adding your new dependencies -- make sure to add those changes in your next commit!","title":"Adding new dependencies"},{"location":"setup/#removing-a-dependency","text":"pixi remove package_name","title":"Removing a dependency"},{"location":"setup/#documentation","text":"Mkdocs is the documentation engine that takes hand-written markdown files to a project website. Please read more at https://www.mkdocs.org/. Mkdocstrings is a mkdocs extension that allows autogenerated documentation to be made, by scraping type hints and documentation strings for any python modules within the project.","title":"Documentation"},{"location":"setup/#building-and-serving-the-documentation-commands-locally","text":"mkdocs new [dir-name] - Create a new project. mkdocs serve - Start the live-reloading docs server. mkdocs build - Build the documentation site. mkdocs -h - Print help message and exit.","title":"Building and serving the documentation commands locally"},{"location":"setup/#documentation-files-layout","text":"mkdocs.yml # The configuration file. docs/ images/ # Folder for storing local images for documentation, including for the README.md. index.md # The documentation homepage. ... # Other markdown pages.","title":"Documentation files layout"},{"location":"setup/#add-a-new-page-or-subpage","text":"To add a new page, in mkdocs.yml add the page (or subpage) by: site_name: IceDyno Documentation nav: - Home: index.md - Setup: setup.md - New Page: newpage.md - New SubPage: newsubpage.md - ...","title":"Add a new page or subpage"},{"location":"setup/#autogenerate-documentation-for-an-icedyno-module","text":"Add to a markdown file something like this: ::: icedyno.preprocess","title":"Autogenerate documentation for an IceDyno module"},{"location":"workflow/","text":"IceDyno Dev Workflow \u00b6 This is where we should document how we should merge/rebase/squash/etc and things we should know while working.","title":"Workflow"},{"location":"workflow/#icedyno-dev-workflow","text":"This is where we should document how we should merge/rebase/squash/etc and things we should know while working.","title":"IceDyno Dev Workflow"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"IceDyno Documentation \u00b6 Short-Term Forecasting of Sea-Ice Edge Boundaries in the Arctic \u00b6 Authors: Ruchi Asthana, Julieanna Bacon, Brendon Gory, Matthew Thanos, Soolu Thomas Welcome to the project! This is a data science Master's capstone through Harvard University's Extension School, in collaboration with NOAA.","title":"Home"},{"location":"#icedyno-documentation","text":"","title":"IceDyno Documentation"},{"location":"#short-term-forecasting-of-sea-ice-edge-boundaries-in-the-arctic","text":"Authors: Ruchi Asthana, Julieanna Bacon, Brendon Gory, Matthew Thanos, Soolu Thomas Welcome to the project! This is a data science Master's capstone through Harvard University's Extension School, in collaboration with NOAA.","title":"Short-Term Forecasting of Sea-Ice Edge Boundaries in the Arctic"},{"location":"GH-cheatsheet/","text":"GitHub Cheatsheet \u00b6 Here's a quick cheatsheet on getting started with a GitHub project, if you are new to GitHub. Before we start, anything that is within the angle brackets ( < or > ) should be replaced as a whole. For example: <your-username> should be replaced to something like SooluThomas Table of contents \u00b6 Set up SSH keys Clone repository Create feature branches Check username and email in your local git Add, commit and push changes to feature branch Create Pull Request Pull changes from the main to feature branch Set up SSH keys \u00b6 Most of GitHub's documentation is pretty good. So pointing to GH docs for 1. Check for existing SSH key 2. Generate new SSH key > Its easier to just follow the 3 steps mentioned under \"Generating a new SSH key\" section. 3. Add a new SSH key 4. Test your SSH connection Clone repository \u00b6 Once SSH keys are set up, in your terminal move to the which ever directory you want to have the local repo copy to live using the command cd Documents/<your-folder-path>/Capstone Then clone the repo using the command git clone git@github.com:NOAA-HES-Capstone/icedyno.git cd icedyno (Tip: the link was obtained from the repo -> green button called \"Code\" on top right of the repo -> SSH) Once this is done, you should be able to see the main branch (by default) locally. Create feature branches \u00b6 Create a branch using the command git checkout -b <your-initials>/<branch-name> # This command can show you which branch you are in # The * shows the current branch you are in git branch # you can use `git checkout main` to go to main branch and then # `git checkout <branch-name>` to go to different branch Check username and email in your local git \u00b6 This is an optional step but might be nice to have. This is a one-time thing to do. Run the following: git config user.name git config user.email If this is showing the correct github username and email, you are good. Otherwise, run git config user.name <your-username> git config user.email <your-registered-email> Add, commit and push changes to feature branch \u00b6 # This will show us a summary of the files changed when compared main branch git status # Add the files that were changed # It is always best to add the file names rather than to use `git add *` # so that unwanted files don't get added git add <path>/<file-name> # Commit your changes git commit -m \"Type out commit message with a one line summary briefing the changes\" # TIP: if you want to add more descriptive commit add -m \"descriptive message\" # after the one line summary message # [ALWAYS] Push commit to your branch git push origin <your-initials>/<branch-name> Create Pull Request \u00b6 If you are pushing from a branch for the first time , the first commit will show a link that point to creating a pull request (PR) directly. It should be something like Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 1.36 KiB | 1.36 MiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'soo/add-gh-cheatsheat' on GitHub by visiting remote: https://github.com/NOAA-HES-Capstone/icedyno/pull/new/soo/add-gh-cheatsheat remote: To github.com:NOAA-HES-Capstone/icedyno.git * [new branch] soo/add-gh-cheatsheat -> soo/add-gh-cheatsheat Another way to open a PR is going to the repo itself and find your branch name under the branch selector in the repository. After you click on it, it should have a button to create a pull request. Pull changes from the main to feature branch \u00b6 There could be cases where other PRs could be merged before ours and so we will need to pull those changes in our branch before we can merge or to make sure that our work doesn't break anything with the new changes made in the main branch. For this we can use # Fetch all the changes from remote to local git fetch # pull the changes from main to our feature branch git pull origin main If your are pulling for the first time in that repo, the might be a lot more that will be asked in the terminal and run the command for merge which is something like git config pull.rebase false Let's keep this file growing with the GitHub tips that you get know and would like to share with others.","title":"GitHub"},{"location":"GH-cheatsheet/#github-cheatsheet","text":"Here's a quick cheatsheet on getting started with a GitHub project, if you are new to GitHub. Before we start, anything that is within the angle brackets ( < or > ) should be replaced as a whole. For example: <your-username> should be replaced to something like SooluThomas","title":"GitHub Cheatsheet"},{"location":"GH-cheatsheet/#table-of-contents","text":"Set up SSH keys Clone repository Create feature branches Check username and email in your local git Add, commit and push changes to feature branch Create Pull Request Pull changes from the main to feature branch","title":"Table of contents"},{"location":"GH-cheatsheet/#set-up-ssh-keys","text":"Most of GitHub's documentation is pretty good. So pointing to GH docs for 1. Check for existing SSH key 2. Generate new SSH key > Its easier to just follow the 3 steps mentioned under \"Generating a new SSH key\" section. 3. Add a new SSH key 4. Test your SSH connection","title":"Set up SSH keys"},{"location":"GH-cheatsheet/#clone-repository","text":"Once SSH keys are set up, in your terminal move to the which ever directory you want to have the local repo copy to live using the command cd Documents/<your-folder-path>/Capstone Then clone the repo using the command git clone git@github.com:NOAA-HES-Capstone/icedyno.git cd icedyno (Tip: the link was obtained from the repo -> green button called \"Code\" on top right of the repo -> SSH) Once this is done, you should be able to see the main branch (by default) locally.","title":"Clone repository"},{"location":"GH-cheatsheet/#create-feature-branches","text":"Create a branch using the command git checkout -b <your-initials>/<branch-name> # This command can show you which branch you are in # The * shows the current branch you are in git branch # you can use `git checkout main` to go to main branch and then # `git checkout <branch-name>` to go to different branch","title":"Create feature branches"},{"location":"GH-cheatsheet/#check-username-and-email-in-your-local-git","text":"This is an optional step but might be nice to have. This is a one-time thing to do. Run the following: git config user.name git config user.email If this is showing the correct github username and email, you are good. Otherwise, run git config user.name <your-username> git config user.email <your-registered-email>","title":"Check username and email in your local git"},{"location":"GH-cheatsheet/#add-commit-and-push-changes-to-feature-branch","text":"# This will show us a summary of the files changed when compared main branch git status # Add the files that were changed # It is always best to add the file names rather than to use `git add *` # so that unwanted files don't get added git add <path>/<file-name> # Commit your changes git commit -m \"Type out commit message with a one line summary briefing the changes\" # TIP: if you want to add more descriptive commit add -m \"descriptive message\" # after the one line summary message # [ALWAYS] Push commit to your branch git push origin <your-initials>/<branch-name>","title":"Add, commit and push changes to feature branch"},{"location":"GH-cheatsheet/#create-pull-request","text":"If you are pushing from a branch for the first time , the first commit will show a link that point to creating a pull request (PR) directly. It should be something like Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 1.36 KiB | 1.36 MiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Create a pull request for 'soo/add-gh-cheatsheat' on GitHub by visiting remote: https://github.com/NOAA-HES-Capstone/icedyno/pull/new/soo/add-gh-cheatsheat remote: To github.com:NOAA-HES-Capstone/icedyno.git * [new branch] soo/add-gh-cheatsheat -> soo/add-gh-cheatsheat Another way to open a PR is going to the repo itself and find your branch name under the branch selector in the repository. After you click on it, it should have a button to create a pull request.","title":"Create Pull Request"},{"location":"GH-cheatsheet/#pull-changes-from-the-main-to-feature-branch","text":"There could be cases where other PRs could be merged before ours and so we will need to pull those changes in our branch before we can merge or to make sure that our work doesn't break anything with the new changes made in the main branch. For this we can use # Fetch all the changes from remote to local git fetch # pull the changes from main to our feature branch git pull origin main If your are pulling for the first time in that repo, the might be a lot more that will be asked in the terminal and run the command for merge which is something like git config pull.rebase false Let's keep this file growing with the GitHub tips that you get know and would like to share with others.","title":"Pull changes from the main to feature branch"},{"location":"setup/","text":"Setup \u00b6 To get started, clone the repo, checkout this branch, using Linux install pixi with: curl -fsSL https://pixi.sh/install.sh | bash For Mac, install via homebrew with brew install pixi If using windows, install pixi with: iwr -useb https://pixi.sh/install.ps1 | iex See here for more info on pixi: https://pixi.sh/. Then to install the project and its dependencies, type: pixi install You could activate the virtual environment with pixi shell (so every command uses the virtual environment until you type exit ) or prefix your commands with pixi run inside the icedyno project folder (ex: pixi run pytest ). To set up the automatic linters (that run every time you commit your work), you would run: pixi run pre-commit install Finish the installation proces with: pixi run pip install -e . If you skip this last step, you will not be able to import icedyno as an installed python library. Testing the set up \u00b6 If you activated the pixi environment, type pytest . If not, type pixi run pytest . You should have one dummy test that runs on that command. What does it look like when the linters and pre-commit hooks run? \u00b6 After you've installed the pre-commit hooks and have changes to commit, this is what the process will look like for committing: You have changes to commit: Commit with a descriptive message: One-time setup of the linters: Our code was not already compliant with the linters, so they \"failed\" our commit and automatically changed things about our code to become compliant: Go ahead and inspect what got modified if you'd like: Add the changes and redo your commit command: Adding new dependencies \u00b6 Just write pixi add conda_or_pip_package_name . You can add multiple dependencies at once (which is better than one at a time, pixi will have to recompute work otherwise) by adding a space between the package names. I.e. pixi add package1 package2 package3 . You'll see that the pixi.toml and pixi.lock files will change after adding your new dependencies -- make sure to add those changes in your next commit! Removing a dependency \u00b6 pixi remove package_name Documentation \u00b6 Mkdocs is the documentation engine that takes hand-written markdown files to a project website. Please read more at https://www.mkdocs.org/. Mkdocstrings is a mkdocs extension that allows autogenerated documentation to be made, by scraping type hints and documentation strings for any python modules within the project. Building and serving the documentation commands locally \u00b6 mkdocs new [dir-name] - Create a new project. mkdocs serve - Start the live-reloading docs server. mkdocs build - Build the documentation site. mkdocs -h - Print help message and exit. Documentation files layout \u00b6 mkdocs.yml # The configuration file. docs/ images/ # Folder for storing local images for documentation, including for the README.md. index.md # The documentation homepage. ... # Other markdown pages. Add a new page or subpage \u00b6 To add a new page, in mkdocs.yml add the page (or subpage) by: site_name: IceDyno Documentation nav: - Home: index.md - Setup: setup.md - New Page: newpage.md - New SubPage: newsubpage.md - ... Autogenerate documentation for an IceDyno module \u00b6 Add to a markdown file something like this: ::: icedyno.preprocess","title":"Setup"},{"location":"setup/#setup","text":"To get started, clone the repo, checkout this branch, using Linux install pixi with: curl -fsSL https://pixi.sh/install.sh | bash For Mac, install via homebrew with brew install pixi If using windows, install pixi with: iwr -useb https://pixi.sh/install.ps1 | iex See here for more info on pixi: https://pixi.sh/. Then to install the project and its dependencies, type: pixi install You could activate the virtual environment with pixi shell (so every command uses the virtual environment until you type exit ) or prefix your commands with pixi run inside the icedyno project folder (ex: pixi run pytest ). To set up the automatic linters (that run every time you commit your work), you would run: pixi run pre-commit install Finish the installation proces with: pixi run pip install -e . If you skip this last step, you will not be able to import icedyno as an installed python library.","title":"Setup"},{"location":"setup/#testing-the-set-up","text":"If you activated the pixi environment, type pytest . If not, type pixi run pytest . You should have one dummy test that runs on that command.","title":"Testing the set up"},{"location":"setup/#what-does-it-look-like-when-the-linters-and-pre-commit-hooks-run","text":"After you've installed the pre-commit hooks and have changes to commit, this is what the process will look like for committing: You have changes to commit: Commit with a descriptive message: One-time setup of the linters: Our code was not already compliant with the linters, so they \"failed\" our commit and automatically changed things about our code to become compliant: Go ahead and inspect what got modified if you'd like: Add the changes and redo your commit command:","title":"What does it look like when the linters and pre-commit hooks run?"},{"location":"setup/#adding-new-dependencies","text":"Just write pixi add conda_or_pip_package_name . You can add multiple dependencies at once (which is better than one at a time, pixi will have to recompute work otherwise) by adding a space between the package names. I.e. pixi add package1 package2 package3 . You'll see that the pixi.toml and pixi.lock files will change after adding your new dependencies -- make sure to add those changes in your next commit!","title":"Adding new dependencies"},{"location":"setup/#removing-a-dependency","text":"pixi remove package_name","title":"Removing a dependency"},{"location":"setup/#documentation","text":"Mkdocs is the documentation engine that takes hand-written markdown files to a project website. Please read more at https://www.mkdocs.org/. Mkdocstrings is a mkdocs extension that allows autogenerated documentation to be made, by scraping type hints and documentation strings for any python modules within the project.","title":"Documentation"},{"location":"setup/#building-and-serving-the-documentation-commands-locally","text":"mkdocs new [dir-name] - Create a new project. mkdocs serve - Start the live-reloading docs server. mkdocs build - Build the documentation site. mkdocs -h - Print help message and exit.","title":"Building and serving the documentation commands locally"},{"location":"setup/#documentation-files-layout","text":"mkdocs.yml # The configuration file. docs/ images/ # Folder for storing local images for documentation, including for the README.md. index.md # The documentation homepage. ... # Other markdown pages.","title":"Documentation files layout"},{"location":"setup/#add-a-new-page-or-subpage","text":"To add a new page, in mkdocs.yml add the page (or subpage) by: site_name: IceDyno Documentation nav: - Home: index.md - Setup: setup.md - New Page: newpage.md - New SubPage: newsubpage.md - ...","title":"Add a new page or subpage"},{"location":"setup/#autogenerate-documentation-for-an-icedyno-module","text":"Add to a markdown file something like this: ::: icedyno.preprocess","title":"Autogenerate documentation for an IceDyno module"},{"location":"workflow/","text":"IceDyno Dev Workflow \u00b6 This is where we should document how we should merge/rebase/squash/etc and things we should know while working. Resolving rebase conflicts with pixi.lock \u00b6 You will only enounter this if you have added/removed dependencies and main has received commits since you first branched that included new/removed dependencies. If you encounter this, please make sure that the pixi.toml contains the (non-duplicated) additions from your commits and main's, then delete the pixi.lock and run pixi install to regnerate the lock file given both sets of dependencies.","title":"Workflow"},{"location":"workflow/#icedyno-dev-workflow","text":"This is where we should document how we should merge/rebase/squash/etc and things we should know while working.","title":"IceDyno Dev Workflow"},{"location":"workflow/#resolving-rebase-conflicts-with-pixilock","text":"You will only enounter this if you have added/removed dependencies and main has received commits since you first branched that included new/removed dependencies. If you encounter this, please make sure that the pixi.toml contains the (non-duplicated) additions from your commits and main's, then delete the pixi.lock and run pixi install to regnerate the lock file given both sets of dependencies.","title":"Resolving rebase conflicts with pixi.lock"}]}
\ No newline at end of file
diff --git a/setup/index.html b/setup/index.html
index d3ca8e9..01186f5 100644
--- a/setup/index.html
+++ b/setup/index.html
@@ -131,6 +131,9 @@ <h1 id="setup">Setup<a class="headerlink" href="#setup" title="Permanent link">&
 <p>To set up the automatic linters (that run every time you commit your work), you would run:<br />
 <code>pixi run pre-commit install</code></p>
 <p><img alt="install_pre_commit" src="../images/install_pre_commit.png" /></p>
+<p>Finish the installation proces with:<br />
+<code>pixi run pip install -e .</code></p>
+<p>If you skip this last step, you will <strong>not</strong> be able to import <code>icedyno</code> as an installed python library. </p>
 <h2 id="testing-the-set-up">Testing the set up<a class="headerlink" href="#testing-the-set-up" title="Permanent link">&para;</a></h2>
 <p>If you activated the pixi environment, type <code>pytest</code>. If not, type <code>pixi run pytest</code>. You should have one dummy test that runs on that command.</p>
 <h2 id="what-does-it-look-like-when-the-linters-and-pre-commit-hooks-run">What does it look like when the linters and pre-commit hooks run?<a class="headerlink" href="#what-does-it-look-like-when-the-linters-and-pre-commit-hooks-run" title="Permanent link">&para;</a></h2>
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 0568036074ce2c28369bcdda7b54d904bf608d61..b83f057a74eef91d96f3b1abf83e6aa0a0d9eb26 100644
GIT binary patch
delta 12
Tcmb=gXOr*d;5a#LB3mT@8U+L{

delta 12
Tcmb=gXOr*d;0Ugp$W{pe7gqzI

diff --git a/workflow/index.html b/workflow/index.html
index 584ab19..319e378 100644
--- a/workflow/index.html
+++ b/workflow/index.html
@@ -81,6 +81,10 @@
             
             <li class="nav-item" data-level="1"><a href="#icedyno-dev-workflow" class="nav-link">IceDyno Dev Workflow</a>
               <ul class="nav flex-column">
+            <li class="nav-item" data-level="2"><a href="#resolving-rebase-conflicts-with-pixilock" class="nav-link">Resolving rebase conflicts with pixi.lock</a>
+              <ul class="nav flex-column">
+              </ul>
+            </li>
               </ul>
             </li>
         </ul>
@@ -89,7 +93,10 @@
                     <div class="col-md-9" role="main">
 
 <h1 id="icedyno-dev-workflow">IceDyno Dev Workflow<a class="headerlink" href="#icedyno-dev-workflow" title="Permanent link">&para;</a></h1>
-<p>This is where we should document how we should merge/rebase/squash/etc and things we should know while working.</p></div>
+<p>This is where we should document how we should merge/rebase/squash/etc and things we should know while working.</p>
+<h2 id="resolving-rebase-conflicts-with-pixilock">Resolving rebase conflicts with pixi.lock<a class="headerlink" href="#resolving-rebase-conflicts-with-pixilock" title="Permanent link">&para;</a></h2>
+<p>You will only enounter this if you have added/removed dependencies and main has received commits since you first branched that included new/removed dependencies.</p>
+<p>If you encounter this, please make sure that the pixi.toml contains the (non-duplicated) additions from your commits and main's, then delete the pixi.lock and run <code>pixi install</code> to regnerate the lock file given both sets of dependencies.</p></div>
             </div>
         </div>