update to reflect macros feature

site/content/docs/guide/plugin/for-developers.md

@@ -8,7 +8,7 @@ A Hipcheck plugin is a separate executable artifact that Hipcheck downloads,
 starts, and communicates with over a gRPC protocol to request data. A plugin's
 executable artifact is the binary, set of executable program files, Docker
 container, or other artifact which can be run as a command line interface
-program through a singular "start command" defined in the plugin's 
+program through a singular "start command" defined in the plugin's
 [manifest file](#plugin-manifest).
 
 The benefit of the executable-and-gRPC plugin design is that plugins can be
@@ -18,7 +18,7 @@ compile their plugin for, and more likely will need to support a handful of
 target platforms. This can be simplified through the optional use of container
 files as the plugin executable artifact.
 
-Once a plugin author writes their plugin, compiles, packages, and 
+Once a plugin author writes their plugin, compiles, packages, and
 [distribute](#distributing-your-plugin) it, Hipcheck users can specify the
 plugin in their policy file for Hipcheck to fetch and use in analysis.
 
@@ -41,10 +41,13 @@ section will describe at a high level how a plugin author can use the SDK, but
 for more detailed information please see the [API docs](https://docs.rs/hipcheck-sdk).
 
 The first step is to add `hipcheck-sdk` as a dependency to your Rust project.
-Next, the SDK provides `prelude` module which authors can import to get access
-to all the essential types it exposes. If you want to manage your imports to
-avoid potential type name collisions you may do so, otherwise simply write `use
-hipcheck_sdk::prelude::*`.
+If you plan to use the macro approach described below, please add the `"macros"`
+feature.
+
+Next, the SDK provides `prelude` module which authors can import to get
+access to all the essential types it exposes. If you want to manage your imports
+to avoid potential type name collisions you may do so, otherwise simply write
+`use hipcheck_sdk::prelude::*`.
 
 ### Defining Query Endpoints
 
@@ -56,8 +59,11 @@ the `Query` trait.
 
 #### Using Proc Macros
 
-The SDK offers an attribute proc macro `query` for marking `async` functions with an
-appropriate signature as query endpoints. The function signature must be of the
+The SDK offers an attribute proc macro `query` for marking `async` functions
+as query endpoints. As a reminder, you must have enabled the `"macros"` feature
+on your `hipcheck_sdk` dependency to use the SDK macros.
+
+To mark an `async fn` as a query endpoint, The function signature must be of the
 form
 
 ```rust
@@ -136,7 +142,7 @@ plugins. In the next subsection we will describe how to do that in more detail.
 
 #### Querying Other Plugins
 
-As mentioned above, the `run()` function receives a handle to a `PluginEngine` instance 
+As mentioned above, the `run()` function receives a handle to a `PluginEngine` instance
 which exposes the following generic function:
 
 ```rust
@@ -223,8 +229,8 @@ to take the `Target` schema (@Todo - link to it), as this is the object type
 passed to the designated query endpoints of all "top-level" plugins declared in
 the Hipcheck policy file.
 
-If you do define a default query endpoint, `Plugin::explain_default_query()` 
-should return a `Ok(Some(_))` containing a string that explains the default 
+If you do define a default query endpoint, `Plugin::explain_default_query()`
+should return a `Ok(Some(_))` containing a string that explains the default
 query.
 
 Lastly, if yours is an analysis plugin, users will need to write [policy
@@ -242,7 +248,7 @@ generally will be compared against an integer/float threshold, you can return a
 ### Running Your Plugin
 
 At this point you now have a struct that implements `Plugin`. The last thing to
-do is write some boilerplate code for starting the plugin server. The Rust SDK 
+do is write some boilerplate code for starting the plugin server. The Rust SDK
 exposes a `PluginServer` type as follows:
 
 ```rust
@@ -263,8 +269,8 @@ impl<P: Plugin> PluginServer<P> {
 
 So, once you have parsed the port from the CLI `--port <PORT>` flag that
 Hipcheck passes to your plugin, you simply pass an instance of your `impl
-Plugin` struct to `PluginServer::register()`, then call `listen(<PORT>).await` 
-on the returned `PluginServer` instance. This function will not return until 
+Plugin` struct to `PluginServer::register()`, then call `listen(<PORT>).await`
+on the returned `PluginServer` instance. This function will not return until
 the gRPC channel with Hipcheck core is closed.
 
 And that's all there is to it! Happy plugin development!
@@ -277,4 +283,4 @@ And that's all there is to it! Happy plugin development!
 
 ## Plugin Manifest
 
-## Plugin Download Manifest
+## Plugin Download Manifest