Docs update

docs/pages/automatic_registration.md

@@ -1,10 +1,7 @@
 # Automatic Registration
 
-The examples show the use of `@container.register` to mark each service. 
-However, if all of them reside in a few select modules then it is possible to automatically register 
-all of them, eliminating the need for the decorator.
-
-To achieve that you can use `container.regiter_all_in_module(module, pattern = "*")` method.
+In addition to using `@container.register` to register each service automatic registration is also possible by
+calling the `container.regiter_all_in_module(module, pattern = "*")` method.
 
 Module represents the top level module containing all your services, optionally a `fnmatch` pattern can be specified
 to only register classes that match the pattern. This does not support registering interfaces.

docs/pages/interfaces.md

@@ -1,11 +1,11 @@
 # Working with Interfaces
 
-When you're autowiring services, you might want to inject an interface rather than directly
-using the concrete implementation. Since Python doesn't have built-in interfaces, 
-you can leverage any class that's marked as abstract within the container.
+When you're autowiring services, you might want to inject an interface rather than 
+the concrete implementation directly. Since Python doesn't have built-in interfaces, you can leverage any class 
+that's marked as abstract within the container.
 
 The following code registers `Engine` as an interface. This implies that `Engine` can't be directly injected. 
-Instead, you need another service that inherits from it, and that service must also be registered in the container.
+Instead a service which will implement the interface must be present and also be registered in the container.
 
 ```python
 @container.abstract

docs/pages/manual_configuration.md

@@ -7,12 +7,12 @@ If you want to avoid using decorators for registration, please refer to [Automat
 Given that parameters can't be resolved from type annotations alone, the `container.wire` method offers two shortcuts 
 for parameter injection: `wire(name="")` and `wire(expr="")`.
 
-To achieve the same outcome without relying on default values, you can actively employ the container's 
+To achieve the same outcome without relying on default values, you can use the container's 
 initialization context. This allows you to manually provide data that the library would 
 otherwise gather from the decorators.
 
 ```python
-container.register_all_in_module(app.services)
+container.register_all_in_module(app.services, "*Service")
 
 # Register parameters individually using add_param
 container.initialization_context.add_param(
@@ -23,7 +23,7 @@ container.initialization_context.add_param(
 container.initialization_context.add_param(
     klass=DbService,
     argument_name="connection_str",
-    parameter_ref=TemplatedString("${cache_dir}/${USER}/db"),
+    parameter_ref=TemplatedString("${cache_dir}/${auth_user}/db"),
 )
 
 # Alternatively, you can update the context in bulk using a dictionary of initializer parameter names as keys

docs/pages/multiple_containers.md

@@ -0,0 +1,14 @@
+# Multiple Containers
+
+As each container has its own state and does not modify the underlying classes, use of multiple containers is possible.
+A few things to keep in mind when using multiple containers.
+
+* The default `wireup.container` is simply an instance just like any other.
+* If a service belongs to multiple containers you can use decorators on them, but it is preferable you manage
+register services without the decorators.
+* To wire parameters use initialization context or the `wire` method. The `wire` method is not bound to any single
+container but merely provides hints as to what should be injected. These hints can be read by any container
+when calling autowire.
+* Use of `@autowire` decorator with multiple containers is unsupported. To bind parameters and services to a method
+call `instance.autowire(fn)()`. The autowire method will return a function where all the arguments that the container
+knows about are passed.