[DATALAD RUNCMD] run codespell throughout

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^

Author: yarikoptic

docs/help.md

@@ -147,7 +147,7 @@ Here's what to have in mind and how to review a pull request:
 
 * Don't worry too much about things like commit message styles, I will squash and merge customizing the commit manually.
 
-* Also don't worry about style rules, there are already automatized tools checking that.
+* Also don't worry about style rules, there are already automated tools checking that.
 
 And if there's any other style or consistency need, I'll ask directly for that, or I'll add commits on top with the needed changes.
 

docs/tutorial/automatic-id-none-refresh.md

@@ -36,7 +36,7 @@ When we create a new `Hero` instance, we don't set the `id`:
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-26]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -125,7 +125,7 @@ We can verify by creating a session using a `with` block and adding the objects.
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:23-41]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -238,7 +238,7 @@ To confirm and understand how this **automatic expiration and refresh** of data
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-58]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -271,7 +271,7 @@ Let's see how it works:
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 // After committing, the objects are expired and have no values
 After committing the session
@@ -335,7 +335,7 @@ You can do that too with `session.refresh(object)`:
 
 {!./docs_src/tutorial/automatic_id_none_refresh/tutorial001.py[ln:33-67]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>
@@ -362,7 +362,7 @@ Here's how the output would look like:
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 // The first refresh
 INFO Engine SELECT hero.id, hero.name, hero.secret_name, hero.age 
@@ -427,7 +427,7 @@ And the output shows again the same data:
 ```console
 $ python app.py
 
-// Output above ommitted 👆
+// Output above omitted 👆
 
 // By finishing the with block, the Session is closed, including a rollback of any pending transaction that could have been there and was not committed
 INFO Engine ROLLBACK

docs/tutorial/code-structure.md

@@ -168,7 +168,7 @@ Let's assume that now the file structure is:
 
 ### Circular Imports and Type Annotations
 
-The problem with circular imports is that Python can't resolve them at <abbr title="While it is executing the program, as oposed to the code as just text in a file stored on disk.">*runtime*</abbr>.
+The problem with circular imports is that Python can't resolve them at <abbr title="While it is executing the program, as opposed to the code as just text in a file stored on disk.">*runtime*</abbr>.
 
 But when using Python **type annotations** it's very common to need to declare the type of some variables with classes imported from other files.
 

docs/tutorial/connect/create-connected-tables.md

@@ -106,7 +106,7 @@ This is the same model we have been using up to now, we are just adding the new
 
 Most of that should look familiar:
 
-The column will be named `team_id`. It will be an integer, and it could be `NULL` in the database (or `None` in Python), becase there could be some heroes that don't belong to any team.
+The column will be named `team_id`. It will be an integer, and it could be `NULL` in the database (or `None` in Python), because there could be some heroes that don't belong to any team.
 
 We add a default of `None` to the `Field()` so we don't have to explicitly pass `team_id=None` when creating a hero.
 

docs/tutorial/create-db-and-table-with-db-browser.md

@@ -164,6 +164,6 @@ Of course, you can also go and take a full SQL course or read a book about SQL,
 
 We saw how to interact with SQLite databases in files using **DB Browser for SQLite** in a visual user interface.
 
-We also saw how to use it to write some SQL directly to the SQLite database. This will be useful to verify the data in the database is looking correclty, to debug, etc.
+We also saw how to use it to write some SQL directly to the SQLite database. This will be useful to verify the data in the database is looking correctly, to debug, etc.
 
 In the next chapters we will start using **SQLModel** to interact with the database, and we will continue to use **DB Browser for SQLite** at the same time to look at the database underneath. 🔍

docs/tutorial/fastapi/tests.md

@@ -82,7 +82,7 @@ But now, we need to deal with a bit of logistics and details we are not paying a
 
 This test looks fine, but there's a problem.
 
-If we run it, it will use the same **production database** that we are using to store our very important **heroes**, and we will end up adding unnecesary data to it, or even worse, in future tests we could end up removing production data.
+If we run it, it will use the same **production database** that we are using to store our very important **heroes**, and we will end up adding unnecessary data to it, or even worse, in future tests we could end up removing production data.
 
 So, we should use an independent **testing database**, just for the tests.
 

docs/tutorial/index.md

@@ -139,7 +139,7 @@ Here are the commands you could use:
     // Remember that you might need to use python3.9 or similar 💡 
     // Create the virtual environment using the module "venv"
     $ python3 -m venv env
-    // ...here it creates the virtual enviroment in the directory "env"
+    // ...here it creates the virtual environment in the directory "env"
     // Activate the virtual environment
     $ source ./env/bin/activate
     // Verify that the virtual environment is active
@@ -161,7 +161,7 @@ Here are the commands you could use:
     ```console
     // Create the virtual environment using the module "venv"
     # >$ python3 -m venv env
-    // ...here it creates the virtual enviroment in the directory "env"
+    // ...here it creates the virtual environment in the directory "env"
     // Activate the virtual environment
     # >$ .\env\Scripts\Activate.ps1
     // Verify that the virtual environment is active

docs/tutorial/insert.md

@@ -171,7 +171,7 @@ The first step is to import the `Session` class:
 ```Python hl_lines="3"
 {!./docs_src/tutorial/insert/tutorial001.py[ln:1-3]!}
 
-# Code below ommitted 👇
+# Code below omitted 👇
 ```
 
 <details>

docs/tutorial/many-to-many/create-data.md

@@ -179,4 +179,4 @@ INFO Engine ROLLBACK
 
 ## Recap
 
-After setting up the model link, using it with **relationship attributes** is fairly straighforward, just Python objects. ✨
+After setting up the model link, using it with **relationship attributes** is fairly straightforward, just Python objects. ✨

docs/tutorial/one.md

@@ -12,7 +12,7 @@ Let's see the utilities to read a single row.
 
 ## Continue From Previous Code
 
-We'll continue with the same examples we have been using in the previous chapters to create and select data and we'll keep udpating them.
+We'll continue with the same examples we have been using in the previous chapters to create and select data and we'll keep updating them.
 
 <details>
 <summary>👀 Full file preview</summary>