Skip to content

Commit

Permalink
Bump version (#6)
Browse files Browse the repository at this point in the history
  • Loading branch information
nightblure authored Sep 20, 2024
1 parent 99a5260 commit 593ddd5
Show file tree
Hide file tree
Showing 6 changed files with 93 additions and 7 deletions.
53 changes: 51 additions & 2 deletions docs/containers/resolving.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,51 @@
# Resolving
soon...
# Providers and resolving

## Providers

Providers are a wrapper over the objects you plan to use in your application code. Providers are able to work with different objects, but for the same purpose - for resolving and assembling objects. At a minimum, there are the following reasons (and clear advantages) for introducing an abstraction such as a provider:
- ability to distinguish ‘normal’ function parameters from providers in order to automatically **inject** arguments using the ``@inject`` decorator;

- object **lifecycle management**;

- **simple** and ubiquitous **reuse** - instead of another object build with parameter injection,
you just need to ask the provider to resolve the object to be wrapped, the provider will do it all by itself;

- possibility of **overriding/substitution** of object parameters and the object itself for other objects
(which is incredibly useful when writing tests);

- **declarative style of building** complex objects with all the advantages of the above included.


## Resolving

**Resolving** is the **process** of **building and receiving** a ready-to-use object from the provider.
You can ask the provider to build and give you a ready-to-use object,
you just need to tell the provider the rules for building it -
usually a future object class or callable-object and positional and/or keyword arguments.
Please refer to the documentation section with the available providers
([transient](https://injection.readthedocs.io/latest/providers/transient.html),
[singeton](https://injection.readthedocs.io/latest/providers/singleton.html) and etc.)

Below is an **example** of a provider definition and a resolving object representing a container for storing some data:
```python3
from dataclasses import dataclass

from injection.providers.transient import Transient


@dataclass
class SomeDataclass:
int_value: int
some_string_value: str


if __name__ == '__main__':
provider = Transient(SomeDataclass, int_value=5, some_string_value='hello')
resolved_object = provider()
print(resolved_object)

>> .venv/bin/python3 example.py
SomeDataclass(int_value=5, some_string_value='hello')

Process finished with exit code 0
```
19 changes: 19 additions & 0 deletions docs/dev/contributing.md
Original file line number Diff line number Diff line change
@@ -1 +1,20 @@
# Contributing

Injection is an open source solution, so any suggestions and suggestions are welcome.
You can describe [bug reports and errors](https://github.com/nightblure/injection/issues)
in the project release, and also send [merge requests](https://github.com/nightblure/injection/pulls)
with fixes and new features!

Modern packages, dependencies and practices were used in the development of the Injection:
* linter and formatter - [Ruff](https://docs.astral.sh/ruff/);
* dependency manager - [PDM](https://pdm-project.org/en/latest/);
* package builder - [Hatch](https://github.com/pypa/hatch);
* testing - [pytest](https://github.com/pytest-dev/pytest);
* assembly and documentation management - [Sphinx](https://www.sphinx-doc.org/en/master/).

The following will describe some useful steps for local development:
* to install dependencies, use the command `make deps`;
* to run the tests, use the command `make test`;
* to start pre-commit hooks and linter, use the command `make lint`;
* to install dependencies for the documentation server, use the command `make docs-deps`;
* to start the server with documentation locally, use the command `make docs-server`.
1 change: 0 additions & 1 deletion docs/providers/coroutine.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,5 +22,4 @@ class DIContainer(DeclarativeContainer):
if __name__ == "__main__":
arg1, arg2 = asyncio.run(DIContainer.provider())
assert (arg1, arg2) == (1, 2)

```
2 changes: 0 additions & 2 deletions docs/providers/object.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,4 @@ class Container(DeclarativeContainer):
if __name__ == "__main__":
assert Container.provider1() == "string"
assert Container.provider2() == 13425


```
24 changes: 23 additions & 1 deletion docs/providers/partial_callable.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,25 @@
# Partial callable

soon...
**Partial callable** it is a provider very similar in principle to the mechanics of the callable provider,
but works a bit differently and allows for flexibility in some specific situations.

Let's imagine that we are in a case when we know some values of parameters of a future object right now,
but some values will be known in the future (in runtime).
Obviously, resolving such a provider will not make any sense until the values of all its parameters are known.
But this provider allows you to flexibly fix the values of previously known parameters of the future object,
and the remaining values can be passed at the moment when these values are determined.

## Example
```python3
from injection.providers import PartialCallable


def some_function(a: str, b: int, *, c: str):
return a, b, c


if __name__ == '__main__':
provider = PartialCallable(some_function, 1, 99)
callable_object = provider()
assert callable_object(c=5) == (1, 99, 5)
```
1 change: 0 additions & 1 deletion docs/providers/transient.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,5 +24,4 @@ if __name__ == "__main__":
instance2 = DIContainer.provider()

assert instance1 is not instance2

```

0 comments on commit 593ddd5

Please sign in to comment.