Nameko-injector

Latest version: v1.1.2

Safety actively analyzes 675368 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

1.1.2

Problem
-------
`corolocal.local` keeps references to all the coroutines (green threads) and the
resources allocated in the scope for that thread. It prevents GC collecting used
injectables.

Solution
--------
Manually clean scope storage in the end of each
request (`NamekoInjectorProvider.worker_teardown`)

1.1.1

Context
-------
It's so common that other dependencies depend on HTTP request object that we
need to provide one by default. For instance other dependencies may take some
data from the headers of the request or arguments.

Solution
--------
Bind the request instance to werkzeug's class that is used by nameko.
Do it right in the nameko provider - no need to build a provider that depends on
nameko worker context etc.

The only problem was that with my current approach using parent-child injector - it doesn't work. All the providers defined on parent that depend on request cannot access that request, because parent injector doesn't know about children.

Now we don't create child injector but instead put the current request directly in the scope, same happens with worker_context. Only when testing test_injector we use child injector.

Testing
-------
Test case provided.

1.1.0

Problem
-------
Some resources in request scope need to be closed (freed). It's not currently
supported.

Solution
--------
Create a new type of scope that's aware about resources with 'close' method.
Name of this special method is hardcoded. Probably we could use protocol in this
case - `Closable`.

It's a separate type of scope to make the fact that resource will be closed more
explicit. When one of the resources cannot be closed, the failure will be logged
but teardown call is not failed so the rest can be closed.

**Second change** is that ServiceContainer is now in singleton scope as it
should be.

Testing
-------
Added test cases.

1.0.1

Fix request scope (3)
Problem
-------
Provider result in scope of the request is not cached therefored each time we try to
access an object we get a new instance of it when callable provider is used.
It's not a desired behaviour. Instead we should get the same object regardless
how many times it's injected.

Decision
--------
Use eventlet.corolocal storage. It's like threadlocal but for coroutines.

Testing
-------
Added test cases to ensure that we inject the same objet that is bound in
request-scope.

1.0.0

Problem
-------
It's not safe to bind WorkerContext to the injector used in the class of the
service as it will potentially conflict with different from other call.

Decisions
---------
- Do not use Mapping in the NamekoInjector init. It's not really useful. Take
the same arguments as `injector.Injector`.
- Use child injectors on each service call to bind WorkerContext and that child
injector is used to resolve the dependencies for the entry point method.
Document better code.
- Improve pytest fixtures
- Rename scope from `request` to `request_scope`, it's less ambiguous.

Docs
----
Readme updated with some details about the available fixtures.

Links

Releases

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.