Removed feature interface from docs (#346)

* removed feature interface from docs

* readded removed code

* Quick start

* Added entry points

* Scripting fix

* Added wams compilation help, last feature remove, remove runtime handle

* Update the diff and versions where this is available

* Update docs/src/contracts/wasm-compilation.md

Co-authored-by: CyberHoward <[email protected]>

* Nits

---------

Co-authored-by: Kayanski <[email protected]>
Co-authored-by: Kayanski <[email protected]>
Co-authored-by: CyberHoward <[email protected]>

Author: 3 people

contracts/counter/src/interface.rs

@@ -6,9 +6,12 @@ use crate::msg::{ExecuteMsg, InstantiateMsg, MigrateMsg, QueryMsg};
 
 pub const CONTRACT_ID: &str = "counter_contract";
 
+// ANCHOR: interface_macro
 #[interface(InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg, id = CONTRACT_ID)]
 pub struct CounterContract;
+// ANCHOR_END: interface_macro
 
+// ANCHOR: uploadable_impl
 impl<Chain: CwEnv> Uploadable for CounterContract<Chain> {
     /// Return the path to the wasm file corresponding to the contract
     fn wasm(&self) -> WasmPath {
@@ -28,6 +31,7 @@ impl<Chain: CwEnv> Uploadable for CounterContract<Chain> {
         )
     }
 }
+// ANCHOR_END: uploadable_impl
 // ANCHOR_END: custom_interface
 
 use cw_orch::anyhow::Result;

docs/src/SUMMARY.md

@@ -12,6 +12,7 @@
   - [Environment Vars](./contracts/env-variable.md)
   - [Scripting](./contracts/scripting.md)
   - [Integration Tests](./contracts/integration-tests.md)
+  - [Wasm Compilation](./contracts/wasm-compilation.md)
 
 - [Project Setup](./setup/index.md)
   - [Single Contract](./setup/single-contract.md)

docs/src/contracts/entry-points.md

@@ -11,8 +11,6 @@ To get started, find the `ExecuteMsg` definition for your contract. In our case
 {{#include ../../../contracts/counter/src/msg.rs:exec_msg}}
 ```
 
-Again we feature flag the function generation to prevent cw-orchestrator entering as a dependency when building your contract.
-
 The functions are implemented as a trait named `ExecuteMsgFns` which is implemented on any interface that uses this `ExecuteMsg` as an entrypoint message.
 
 Using the trait then becomes as simple as:
@@ -30,6 +28,8 @@ Generating query functions is a similar process but has the added advantage of u
 {{#include ../../../contracts/counter/src/msg.rs:query_msg}}
 ```
 
+Keep in mind that you **NEED** to derive the `cosmwasm_schema::QueryResponses` trait on your QueryMsgs for the `QueryFns` macro to compile.
+
 Using it is just as simple as the execution functions:
 
 ```rust,ignore

docs/src/contracts/env-variable.md

@@ -21,7 +21,7 @@ You can provide mnemonics directly to the `Daemon` using the following environme
 Optional, accepted values: Path to a valid file
 Default value: `~./cw-orchestrator/state.json`
 
-This environment variable indicates the location of the state file that `cw-orch` will use to save on-chain state (addresses and code ids). Here is the behavior of this env variable :
+This environment variable indicates the location of the state file that `cw-orch` will use to save on-chain state (addresses and code ids). Here is the behavior of this env variable:
 
 - `folder/file.json` will resolve to `~/.cw-orchestrator/folder/file.json`
 - `./folder/file.json` will resolve `$pwd/folder/file.json`
@@ -33,7 +33,7 @@ This environment variable indicates the location of the state file that `cw-orch
 Optional, accepted values: Path to a valid directory
 
 Path where the wasms will be fetched. This is used by `ArtifactsDir::env()` inside the code.
-This is used in case you are using different tools than what is produced by <a href="https://github.com/CosmWasm/rust-optimizer" target="_blank">rust-optimizer</a>. Prefer using the following macro if you are using `wasm`s produced by `rust-optimizer` :
+This is used in case you are using different tools than what is produced by <a href="https://github.com/CosmWasm/rust-optimizer" target="_blank">rust-optimizer</a>. Prefer using the following macro if you are using `wasm`s produced by `rust-optimizer`:
 
 ```rust,ignore
 artifacts_dir_from_workspace!()
@@ -85,7 +85,7 @@ Defaults to `false`
 
 Some actions require user-intervention. If set to true, this disables those interventions. Useful when working in scripts that can't handle user-intervention.
 
-Supported actions :
+Supported actions:
 
 - Balance checks. When set to `true`, if the gas token balance is too low to submit a transaction, it will error. See [Disable balance assertion](#cw_orch_disable_wallet_balance_assertion).
 - Deployment checks. When set to `true`, if no deployment file is detected when deploying a structure using the `Deploy::multi_deploy` function, it will deploy to all provided chains without asking for approval.
@@ -94,18 +94,18 @@ Supported actions :
 
 ### RUST_LOG
 
-Optional, accepted values : `debug`, `error`, `info`, `warn`,  `trace`
+Optional, accepted values: `debug`, `error`, `info`, `warn`,  `trace`
 
  `RUST_LOG` defines the Log level for the application. This is actually a `Rust` flag that we use inside `cw-orch`. If working with this environment variable, don't forget to also initialize a logger at the beginning of you application to be able to see the output. You can work with <a href="https://crates.io/crates/pretty_env_logger/" target="_blank">pretty_env_logger</a> for instance.
 
 ### CW_ORCH_SERIALIZE_JSON
 
-Optional, accepted values : `false`, `true`
+Optional, accepted values: `false`, `true`
 
 If equals to `true`, in the output logs, cw-orch will serialize the contract messages (instantiate, execute, query,... ) as JSON. This replaces the standard Rust Debug formatting and allows for easy copying and sharing of the executed messages.
 
 ### CW_ORCH_DISABLE_LOGS_ACTIVATION_MESSAGE
 
-Optional, accepted values : `false`, `true`
+Optional, accepted values: `false`, `true`
 
 By default if the logs are not enabled, `cw-orch` wil print a warning message to invite users to activate the logging capabilities of cw-orch. if equals to `true`, this env variable disables the warning message.

docs/src/contracts/interfaces.md

@@ -4,7 +4,7 @@ Interfaces are virtual wrappers around CosmWasm contracts. They allow you to int
 
 > **Reminder**: You can find the code for this example in the <a href="https://github.com/AbstractSDK/cw-orchestrator/tree/main/contracts/counter" target="_blank">cw-orch counter-contract folder</a>.
 >
-> If you are a fast or visual learner, you can find a <a href="https://github.com/AbstractSDK/cw-orch-counter-example/compare/e0a54b074ca1a894bb6e58276944cf2013d152f2..64623d2141c04e4ba42dc6f9ef1a1daccc932d4a" target="_blank">**Before**-**After**</a> view of the `cw-orch` integration process in the sample contract.
+> If you are a fast or visual learner, you can find a <a href="https://github.com/AbstractSDK/cw-orch-counter-example/compare/e0a54b074ca1a894bb6e58276944cf2013d152f2..17f505758734fd3cfe3b4f7cede341376c930e98" target="_blank">**Before**-**After**</a> view of the `cw-orch` integration process in the sample contract.
 
 ## Creating an Interface
 

docs/src/contracts/scripting.md

@@ -1,6 +1,6 @@
 # Writing and Executing Scripts
 
-Now that we have the interface written for our contract, we can start writing scripts to deploy and interact with it on a real blockchain. We'll do this by adding a `examples` folder in <a href="https://abstract.money" target="_blank">Abstract</a>[the counter contract](https://github.com/AbstractSDK/cw-orchestrator/tree/main/contracts/counter) and add our deploy script there. We only provide an overview of how scripting can be done here. Find our more about how to make your scripting dreams come true on the [Daemon page](../integrations/daemon.md).
+Now that we have the interface written for our contract, we can start writing scripts to deploy and interact with it on a real blockchain. We'll do this by adding a `examples` folder in <a href="https://github.com/AbstractSDK/cw-orchestrator/tree/main/contracts/counter" target="_blank">the counter contract</a> and add our deploy script there. We only provide an overview of how scripting can be done here. Find our more about how to make your scripting dreams come true on the [Daemon page](../integrations/daemon.md).
 
 ## Setup
 
@@ -11,14 +11,13 @@ mkdir counter/examples
 touch counter/examples/deploy.rs
 ```
 
-Then we want to add the required dependencies to the `dev-dependencies` section of our `Cargo.toml` file. We'll need `dotenv` to load our environment variables and `pretty_env_logger` to log to stdout. We're using `examples` instead of `bin` because setting a feature on an optional dependency is not supported.
+Then we want to add the required dependencies to the `dev-dependencies` section of our `Cargo.toml` file. We'll need `dotenv` to load our environment variables and `pretty_env_logger` to log to stdout.
 
 ```toml
 [dev-dependencies]
 # Deps for deployment
 dotenv = { version = "0.15.0" } # Enables loading of .env files
 pretty_env_logger = { version = "0.5.0" } # Enables logging to stdout and prettifies it
-counter-contract = { path = ".", features = ["interface"] } # Allows to activate the `interface` feature for examples and tests 
 ```
 
 Now we're ready to start writing our script.

docs/src/contracts/wasm-compilation.md

@@ -0,0 +1,44 @@
+# Wasm Compilation
+
+`cw-orch` was designed to help you test, deply, script and maintaint your application. None of its features include in-contract operations. cw-orch interfaces, macros and helpers can't be used inside a wasm smart contract.
+
+In case you use one of the cw-orch features inside you smart-contract, the compilation will send an error anyway, so that we are **SURE** you are not using un-intended features inside your contract.
+
+## Importing cw-orch
+
+Importing `cw-orch` as a dependency in your smart contract is not a problem. We have built this library such that every feature that cw-orch imports, uses or exports is not included when compiled for Wasm. This means that you are safe to use any cw-orch feature when developing your application, creating interfaces, exporting features, because none of it will land in your contract.
+
+In order to make sure you don't encounter wasm compilation errors, you should follow the guidelines outlined in the next section.
+
+## Guidelines
+
+### Imports
+
+Import cw-orch without a worry, this won't include unnecessary dependencies and bloat your smart-contract. Be careful of the features you import `cw-orch` with because they might increase your compile time (especially `daemon` and `osmosis-test-tube`). 
+
+### Interface
+
+The interface macro itself compiles to Wasm to empty traits. So this macro can be used anywhere in your contract. This **IS** smart-contract safe: 
+
+```rust,ignore
+{{#include ../../../contracts/counter/src/interface.rs:interface_macro}}
+```
+
+However, the `Uploadable` traits implementation **IS NOT** safe for smart contracts and needs to import namely `cw-multi-test` elements that we don't remove from WASM compilation. The following code needs to be flagged to not be compiled inside Wasm contracts:
+
+```rust,ignore
+#[cfg(not(target_arch = "wasm32"))]
+{{#include ../../../contracts/counter/src/interface.rs:uploadable_impl}}
+```
+
+### Entry Points
+
+The entry points are easy to work with as they compile to empty traits inside Wasm. So you can define them, import and export them in your contract without having to care about compilation targets. Furthermore, those traits are optimized out when getting your contract ready to upload on a chain. The syntax use in the 2 following examples is WASM safe:
+
+```rust,ignore
+{{#include ../../../contracts/counter/src/msg.rs:exec_msg}}
+```
+
+```rust,ignore
+{{#include ../../../contracts/counter/src/lib.rs:fn_re_export}}
+```

docs/src/integrations/daemon.md

@@ -4,7 +4,7 @@
 
 ## Quick Start
 
-Interacting with the `daemon` is really straightforward. How to creating a daemon instance is shown below:
+Interacting with the `daemon` is really straightforward. Creating a daemon instance is shown below:
 
 ```rust,ignore
     use cw_orch::prelude::*;
@@ -15,31 +15,11 @@ Interacting with the `daemon` is really straightforward. How to creating a daemo
 - The `chain` parameter allows you to specify which chain you want to interact with. The chains that are officially supported can be found in the `cw_orch::daemon::networks` module.
   You can also add additional chains yourself by simply defining a variable of type <a href="https://docs.rs/cw-orch/latest/cw_orch/daemon/struct.ChainInfo.html" target="_blank">`ChainInfo`</a> and using it in your script. Don't hesitate to open a PR on the <a href="https://github.com/AbstractSDK/cw-orchestrator" target="_blank">cw-orchestrator repo</a>, if you would like us to include a chain by default. The variables needed for creating the variable can be found in the documentation of the chain you want to connect to or in the <a href="https://cosmos.directory" target="_blank">Cosmos Directory</a>.
 
-- The `handle` parameter is a *tokio runtime handle*. 
-  <details>
-    <summary>If you <strong>don't know</strong> what that means</summary>
-    
-    
-  You don't need to know all the intricacies of <a href="https://rust-lang.github.io/async-book/" target="_blank">tokio and rust-async</a> to use daemons. If you don't have time to learn more, you can simply use the snippet above and not touch the runtime creation. However for more advanced `daemon` usage and also for your culture, don't hesitate to learn about those wonderful processes and their management.
-        
-  </details>
-
-  <details>
-    <summary>If you <strong>know</strong> what that means</summary>
-
-  This handler is used because all the front-facing daemon methods are synchronous. However everything that's happening in the background is asynchronous. This handle is used exclusively to await asynchronous function: 
-  ```rust,ignore
-      runtime.block_on(...)
-
-  ```
-  Because creating runtimes is a costly process, we leave the handler creation and management to the user.
-        
-  </details>
-
-
 This simple script actually hides another parameter which is the `LOCAL_MNEMONIC` environment variable. This variable is used when interacting with local chains. See the part dedicated to [Environment Vars](../contracts/env-variable.md) for more details.
 
 > **_NOTE:_** When using `daemon`, you are interacting directly with a live chain. The program won't ask you for your permission at each step of the script. We advise you to test **ALL** your deployments on test chain before deploying to mainnet.
+>
+> Under the hood, the `DaemonBuilder` struct creates a `tokio::Runtime`. Be careful because this builder is not usable in an `async` function. In such function, you can use <a href="https://docs.rs/cw-orch/latest/cw_orch/daemon/struct.DaemonAsync.html" target="_blank">`DaemonAsync`</a>
 
 ## Interacting with contracts
 
@@ -101,7 +81,7 @@ Here are the available options and fields you can use in the builder object:
 
 - `chain` (*required*) specifies the chain the `daemon` object will interact with. <a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.chain" target="_blank">Documentation Link</a>
 - `deployment_id` (*optional*) is used when loading and saving blockchain state (addresses and code-ids). It is useful when you have multiple instances of the same contract on a single chain. It will allow you to keep those multiple instances in the same state file without overriding state.<a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.deployment_id" target="_blank">Documentation Link</a>
-- `handle` (*required*) is the `tokio` runtime handled used to await async functions. <a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.handle" target="_blank">Documentation Link</a>
+- `handle` (*optional*) is the `tokio` runtime handled used to await async functions. `cw-orch` provides a default runtime if not specified. <a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.handle" target="_blank">Documentation Link</a>
 - `mnemonic` (*optional*) is the mnemonic that will be used to create the sender associated with the resulting `Daemon` Object. It is not compatible with the `sender` method. <a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.mnemonic" target="_blank">Documentation Link</a>
 - `sender` (*optional*) is the sender that will be uses with the `resulting` Daemon Object. It is not compatible with the `mnemonic` method. <a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.mnemonic" target="_blank">Documentation Link</a>
 - `authz_granter` (*optional*) allows you to use the authz module. If this field is specified, the sender will send transactions wrapped inside an authz message sent by the specified `granter`. <a href="https://docs.cosmos.network/v0.46/modules/authz/" target="_blank">More info on the authz module</a>. <a href="https://docs.rs/cw-orch-daemon/latest/cw_orch_daemon/sync/struct.DaemonBuilder.html#method.authz_granter" target="_blank">Documentation Link</a>