Update README.md template; proofread docs (#741)

Author: droserasprout

.github/workflows/installer.yml

@@ -45,16 +45,20 @@ jobs:
       - name: dipdup new
         run: dipdup new --quiet
 
-      - name: Replace DipDup in project with current HEAD
-        run: cd dipdup_indexer; pdm add -d git+https://github.com/dipdup-io/dipdup.git@${{ github.sha }}
+      - name: Replace DipDup in project with current HEAD (until 7.0)
+        run: cd dipdup_indexer; pdm remove dipdup; pdm add ..
 
       - name: dipdup init
         run: cd dipdup_indexer; dipdup init
 
-      - name: Run lint
-        run: cd dipdup_indexer; pdm run lint
+      - name: pdm all
+        run: cd dipdup_indexer; pdm all
 
-      - name: Deploy scripts to GitHub Pages
+      - name: Copy installer to scripts
+        if: contains(github.ref, 'next')
+        run: cp src/dipdup/install.py scripts/install.py
+
+      - name: Publish scripts to GitHub Pages
         if: contains(github.ref, 'next')
         uses: peaceiris/actions-gh-pages@v3
         with:

docs/1.getting-started/2.core-concepts.md

@@ -13,25 +13,25 @@ Before proceeding to development, let's take a look at basic DipDup concepts.
 
 ## Big picture
 
-DipDup is an SDK for building custom backends for decentralized applications, or for short, indexers. DipDup indexers are off-chain services that aggregate blockchain data from various sources and store it in a database.
+DipDup is an SDK for building custom backends for decentralized applications, or, indexers. DipDup indexers are off-chain services that aggregate blockchain data from various sources and store it in a database.
 
-Each indexer consists of a YAML configuration file and a Python package with models, handlers, and other code. The configuration file describes the inventory of the indexer, i.e., what contracts to index and what data to extract from them. It supports templates, environment variables, and use syntax similar to Subgraph manifest files. The Python package contains models, callbacks and queries. Models describe the domain-specific data structures you want to store in the database. Callbacks implement the business logic, i.e., how to convert blockchain data to your models. Other files in the package are optional and can be used to extend DipDup functionality.
+Each indexer consists of a YAML configuration file and a Python package with models, handlers, and other code. The configuration file describes the inventory of the indexer, i.e., what contracts to index and what data to extract from them. It supports templates, and environment variables, and uses a syntax similar to Subgraph manifest files. The Python package contains models, callbacks and queries. Models describe the domain-specific data structures you want to store in the database. Callbacks implement the business logic, i.e., how to convert blockchain data to your models. Other files in the package are optional and can be used to extend DipDup functionality.
 
-As a result, you get a service responsible for filling the database with the indexed data. Then you can use it to build a custom API backend or integrate with existing ones. DipDup provides Hasura GraphQL Engine integration to expose indexed data via REST and GraphQL with little to no effort, but you can also use other API engines like PostgREST or develop one in-house.
+As a result, you get a service responsible for filling the database with indexed data. Then you can use it to build a custom API backend or integrate with existing ones. DipDup provides Hasura GraphQL Engine integration to expose indexed data via REST and GraphQL with little to no effort, but you can also use other API engines like PostgREST or develop one in-house.
 
 <!-- TODO: SVG include doesn't work -->
 
 ![Generic DipDup setup and data flow](../assets/dipdup.svg)
 
 ## Storage layer
 
-DipDup uses PostgreSQL or SQLite as a database backend. All the data is stored in a single database schema created on the first run. Make sure it's used by DipDup exclusively, since changes in index configuration or models require DipDup to drop the whole database schema and start indexing from scratch. You can, however, mark specific tables as immune to preserve them from being dropped.
+DipDup uses PostgreSQL or SQLite as a database backend. All the data is stored in a single database schema created on the first run. Make sure it's used by DipDup exclusively since changes in index configuration or models require DipDup to drop the whole database schema and start indexing from scratch. You can, however, mark specific tables as immune to preserve them from being dropped.
 
 DipDup does not support database schema migration. Any change in models or index definitions will trigger reindexing. Migrations introduce complexity and do not guarantee data consistency. DipDup stores a hash of the SQL version of the DB schema and checks for changes each time you run indexing.
 
-DipDup applies all updates atomically block by block, ensuring data integrity. If indexing is interrupted, next time DipDup starts, it will check the database state and continue from the last block processed. DipDup state is stored in the database per-index and can be used by API consumers to determine the current indexer head.
+DipDup applies all updates atomically block by block, ensuring data integrity. If indexing is interrupted, the next time DipDup starts, it will check the database state and continue from the last block processed. DipDup state is stored in the database per index and can be used by API consumers to determine the current indexer head.
 
-Index is a set of contracts and rules for processing them as a single entity. Your config can contain more than one index, but they are processed in parallel and cannot share data as execution order is not guaranteed.
+An index is a set of contracts and rules for processing them as a single entity. Your config can contain more than one index, but they are processed in parallel and cannot share data as execution order is not guaranteed.
 
 ## Handling chain reorgs
 

docs/1.getting-started/3.config.md

@@ -43,7 +43,7 @@ Use `config export`{lang="sh"} and `config env`{lang="sh"} commands to check the
 
 ## Environment variables
 
-DipDup supports compose-style variable expansion with optional default value. Use this feature to store sensitive data outside of the configuration file and make your app fully declarative. If required variable is not set, DipDup will fail with an error. You can use these placeholders anywhere throughout the configuration file.
+DipDup supports compose-style variable expansion with an optional default value. Use this feature to store sensitive data outside of the configuration file and make your app fully declarative. If a required variable is not set, DipDup will fail with an error. You can use these placeholders anywhere throughout the configuration file.
 
 ```yaml [dipdup.yaml]
 database:
@@ -57,7 +57,7 @@ There are multiple ways to pass environment variables to DipDup:
 - Export them in the shell before running DipDup
 - Create the env file and pass it to DipDup with the `-e` CLI option
 
-For every config file in `deploy` project directory, DipDup will create a corresponding `.env.default` file with all the variables used in the config. Copy it removing `.default` suffix and fill in the values.
+For every config file in the `deploy` project directory, DipDup will create a corresponding `.env.default` file with all the variables used in the config. Copy it, remove the `.default` suffix and fill in the values.
 
 ```sh [deploy/.env.default]
 POSTGRES_HOST=localhost

docs/1.getting-started/4.package.md

@@ -6,11 +6,11 @@ description: "DipDup is a Python framework for building smart contract indexers.
 
 # Package structure
 
-Each DipDup project consists of a YAML config and a Python package of specific structure. It could be placed anywhere, but needs to be importable. The package name is defined in the config file.
+Each DipDup project consists of a YAML config and a Python package of a specific structure. It could be placed anywhere, but needs to be importable. The package name is defined in the config file.
 
 To generate all necessary directories and files according to config run the `init` command. You should run it every time you significantly change the config file.
 
-The structure of resulting package is the following:
+The structure of the resulting package is the following:
 
 | Path                     | Description                                                     |
 | ------------------------ | --------------------------------------------------------------- |
@@ -29,7 +29,7 @@ There's also a bunch on files in the root directory: .ignore files, pyproject.to
 
 ## ABIs and typeclasses
 
-DipDup uses contract type information to generate dataclasses for developers to work with strictly typed data. Theses dataclasses are generated automatically from contract ABIs. In most cases, you don't need to modify them manually. The process is roughly the following:
+DipDup uses contract type information to generate dataclasses for developers to work with strictly typed data. These dataclasses are generated automatically from contract ABIs. In most cases, you don't need to modify them manually. The process is roughly the following:
 
 1. Contract ABIs are placed in the `abi` directory; either manually or during init.
 2. DipDup converts these ABIs to intermediate JSONSchemas.
@@ -76,4 +76,4 @@ indexer
         └── bar
 ```
 
-The same applies to handler callbacks. Callback alias still needs to be a valid Python module path: lowercase letters, underscores, and dots.
+The same applies to handler callbacks. The callback alias still needs to be a valid Python module path: lowercase letters, underscores, and dots.

docs/1.getting-started/5.models.md

@@ -6,21 +6,21 @@ description: "DipDup is a Python framework for building smart contract indexers.
 
 # Models
 
-To store indexed data in the database, you need to define models. Our storage layer is based on [Tortoise ORM](https://tortoise.github.io/index.html). It's fast, flexible, and have a syntax similar to Django ORM. We have extended it with some useful features like copy-on-write rollback mechanism, caching, and more.
+To store indexed data in the database, you need to define models. Our storage layer is based on [Tortoise ORM](https://tortoise.github.io/index.html). It's fast, flexible, and has a syntax similar to Django ORM. We have extended it with some useful features like a copy-on-write rollback mechanism, caching, and more.
 
-We plan to make things official and fork this library under a new name, but it's not ready yet. For now let's call our implemetation **DipDup ORM**.
+We plan to make things official and fork this library under a new name, but it's not ready yet. For now, let's call our implementation **DipDup ORM****.
 
 Before we begin to dive into the details, here's an important note:
 
 ::banner{type="warning"}
-Please, don't report DipDup issues to the Tortoise ORM bugtracker! We patch it heavily to better suit our needs, so it's not the same library anymore.
+Please, don't report DipDup issues to the Tortoise ORM bug tracker! We patch it heavily to better suit our needs, so it's not the same library anymore.
 ::
 
 You can use [Tortoise ORM docs](https://tortoise.github.io/examples.html) as a reference. We will describe only DipDup-specific features here.
 
 ## Defining models
 
-Project models should be placed in `models` directory in the project root. By default, `__init__.py` module created on project initialization, but you can use any structure you want. Models from nested packages will be discovered automatically.
+Project models should be placed in the `models` directory in the project root. By default, the `__init__.py` module is created on project initialization, but you can use any structure you want. Models from nested packages will be discovered automatically.
 
 Here's an example containing all available fields:
 
@@ -34,7 +34,7 @@ Some limitations are applied to model names and fields to avoid ambiguity in Gra
 
 - Table names must be in snake_case
 - Model fields must be in snake_case
-- Model fields must differ from table name
+- Model fields must differ from the table name
 
 ## Basic usage
 
@@ -62,7 +62,7 @@ See `demo_uniswap` project for real-life examples.
 
 ## Differences from Tortoise ORM
 
-This section describes differences between DipDup and Tortoise ORM. Most likely won't notice them, but it's better to be aware of them.
+This section describes the differences between DipDup and Tortoise ORM. Most likely won't notice them, but it's better to be aware of them.
 
 ### Fields
 
@@ -86,7 +86,7 @@ In Tortoise ORM each subsequent call creates a new queryset using expensive `cop
 
 ### Transactions
 
-DipDup manage transactions automatically for indexes opening one for each level. You can't open another one. Entering a transaction context manually with `in_transaction()` will return the same active transaction. For hooks, there's `atomic` flag in configuration.
+DipDup manages transactions automatically for indexes opening one for each level. You can't open another one. Entering a transaction context manually with `in_transaction()` will return the same active transaction. For hooks, there's `atomic` flag in the configuration.
 
 <!-- ::banner{type="note"}
 

docs/1.getting-started/6.datasources.md

@@ -25,7 +25,7 @@ Index datasources, ones that can be attached to a specific index, are prefixed w
 
 All datasources now share the same code under the hood to communicate with underlying APIs via HTTP. Their configs have an optional section `http` to configure connection settings. You can use it to set timeouts, retry policies, and other parameters.
 
-Each datasource kind has its defaults. Usually, there's no reason to alter these settings unless you use self-hosted instances. In example below, default values are shown:
+Each datasource kind has its defaults. Usually, there's no reason to alter these settings unless you use self-hosted instances. In the example below, default values are shown:
 
 ```yaml [dipdup.yaml]
 datasources:
@@ -48,7 +48,7 @@ datasources:
 
 ## Ratelimiting
 
-Ratelimiting is implenented using "leaky bucket" algorithm. The number of consumed "drops" can be set with each request (defaults to 1), and the bucket is refilled with a constant rate. If the bucket is empty, the request is delayed until it's refilled.
+Ratelimiting is implemented using the "leaky bucket" algorithm. The number of consumed "drops" can be set with each request (defaults to 1), and the bucket is refilled with a constant rate. If the bucket is empty, the request is delayed until it's refilled.
 
 ```python
 response = await datasource.request(

docs/1.getting-started/7.indexes.md

@@ -20,14 +20,15 @@ Multiple indexes are available for different workloads. Every index is linked to
 | [tezos.tzkt.operations_unfiltered](6.tezos_tzkt_operations_unfiltered.md) | Tezos          | TzKT       | untyped operations          |
 | [tezos.tzkt.token_transfers](7.tezos_tzkt_token_transfers.md)             | Tezos          | TzKT       | TZIP-12/16 token transfers  |
 
-Indexes can join multiple contracts considered as a single application. Also, contracts can be used by multiple indexes of any kind, but make sure that they are independent of each other and indexed data don't overlap.
+Indexes can join multiple contracts considered as a single application. Also, contracts can be used by multiple indexes of any kind, but make sure that they are independent of each other and that indexed data don't overlap.
+
 <!-- TODO: here was a link to a place that doesnt exist now -- Make sure to visit {{ #summary getting-started/core-concepts.md#atomicity-and-persistency }}. -->
 
 Handler is a callback function, called when new data has arrived from the datasource. The handler receives the data item as an argument and can perform any actions, e.g., store data in the database, send a notification, or call an external API.
 
 ## Using templates
 
-Index definitions can be templated to reduce the amount of boilerplate code. To create an index from template use the following syntax:
+Index definitions can be templated to reduce the amount of boilerplate code. To create an index from the template use the following syntax:
 
 ```yaml [dipdup.yaml]
 templates:

docs/3.datasources/2.abi_etherscan.md

@@ -5,7 +5,7 @@ description: "DipDup is a Python framework for building smart contract indexers.
 network: "ethereum"
 ---
 
-[Etherscan](https://etherscan.io/) is a popular Ethereum blockchain explorer. It provides a public API to fetch ABIs of verified contracts. DipDup can use it API to fetch ABIs for contracts being indexed.
+[Etherscan](https://etherscan.io/) is a popular Ethereum blockchain explorer. It provides a public API to fetch ABIs of verified contracts. DipDup can use its API to fetch ABIs for contracts being indexed.
 
 To use this datasource, add the following section in config:
 

docs/3.datasources/3.coinbase.md

@@ -14,7 +14,7 @@ datasources:
 
 ## Authorization
 
-If you have a Coinbase API key, you can set it in config and, optionally, increase the ratelimit according to your subscription plan. Otherwise, you will be limited to 10 requests per second.
+If you have a Coinbase API key, you can set it in the config and, optionally, increase the ratelimit according to your subscription plan. Otherwise, you will be limited to 10 requests per second.
 
 ```yaml [dipdup.yaml]
 datasources:

docs/3.datasources/4.evm_node.md

@@ -5,7 +5,7 @@ description: "DipDup is a Python framework for building smart contract indexers.
 network: "ethereum"
 ---
 
-DipDup can connect to any EVM-compatible node via JSON-RPC. It can be used as a "last mile" datasource for EVM indexes (data that not in Subsquid Archives yet) or as a standalone datasource for handlers and hooks.
+DipDup can connect to any EVM-compatible node via JSON-RPC. It can be used as a "last mile" datasource for EVM indexes (data that is not in Subsquid Archives yet) or as a standalone datasource for handlers and hooks.
 
 Examples below show how to connect to Infura and Alchemy nodes for Ethereum mainnet indexes. You can also use your own node, but make sure it has all the necessary data (e.g. archive node).
 
@@ -39,7 +39,7 @@ datasources:
 Don't initialize web3 clients manually! It will break the connection pooling, lock the event loop, and kill your dog.
 ::
 
-To access the client, use `web3` property of the datasource. Underlying web3 client is asynchronous, so you should use `await` keyword to call its methods.
+To access the client, use `web3` property of the datasource. The underlying web3 client is asynchronous, so you should use `await` keyword to call its methods.
 
 ```python
 web3: AsyncWeb3 = ctx.get_evm_node_datasource('mainnet_node').web3