simonw / asyncinject

Run async workflows using pytest-fixtures-style dependency injection

Currently working on Datasette and associated projects. Read my blog or follow @[email protected] on Mastodon.

Recent releases llm-openrouter 0.2 - 2024-05-03 datasette-upload-dbs 0.3.2 - 2024-05-03 ttok 0.3 - 2024-05-02 datasette-enrichments 0.4.2 - 2024-04-27 datasette-secrets 0.2 - 2024-04-26 datasette-test 0.3.2 - 2024-04-26 datasette-test-plugin 0.1 - 2024-04-26 datasette-extract 0.1a6 - 2024-04-25 More recent releases

On my blog Weeknotes: more datasette-secrets, plus a mystery video project - 2024-05-07 Weeknotes: Llama 3, AI for Data Journalism, llm-evals and datasette-secrets - 2024-04-23 Options for accessing Llama 3 from the terminal using LLM - 2024-04-22 AI for Data Journalism: demonstrating what we can do with this stuff right now - 2024-04-17 Three major LLM releases in 24 hours (plus weeknotes) - 2024-04-10 Building files-to-prompt entirely using Claude 3 Opus - 2024-04-08 More on simonwillison.net

TIL Transcribing MP3s with whisper-cpp on macOS - 2024-04-26 A script to capture frames from a QuickTime video - 2024-04-17 impaste: pasting images to piped commands on macOS - 2024-04-04 Installing tools written in Go - 2024-03-26 Google Chrome --headless mode - 2024-03-24 Reviewing your history of public GitHub repositories using ClickHouse - 2024-03-20 More on til.simonwillison.net

How this works

asyncinject's Issues

Record start and end times for each step when logging

Ability to resolve an unregistered function

I'd like to be able to do the following:

async def one():
    return 1

async def two():
    return 2

registry = Registry(one, two)

async def three(one, two):
    return one + two

result = await registry.resolve(three)

Note that three has not been registered with the registry - but it still has its parameters inspected and used to resolve the dependencies.

This would be useful for Datasette, where I want plugins to be able to interact with predefined registries without needing to worry about picking a name for their function that doesn't clash with a name that has been registered by another plugin.

Documentation for .register() method, plus let it accept a name

The method currently looks like this:

asyncinject/asyncinject/__init__.py

Lines 21 to 25 in fd5ef10

	def register(self, fn):
	self._registry[fn.__name__] = fn
	# Clear caches:
	self._graph = None
	self._reversed = None

This isn't yet documented. Also it would be neat if you could do this:

registry.register(lambda x: x.upper(), name="upper")

If name= is not provided it can default to fn.__name__.

Try using __init_subclass__

https://twitter.com/dabeaz/status/1466731368956809219 - David Beazley says:

I think 95% of the problems once solved by a metaclass can be solved by __init_subclass__ instead

Investigate a non-class-based version

I'm thinking about using this with Datasette plugins, which aren't well suited to the current class-based mechanism because plugins may want to register their own additional dependency injection functions.

Documentation needs a smarter example that illustrates graph dependencies

The examples in the README are boring, and don't show how the library can resolve a dependency tree into the most efficient possible mechanism.

Need to come up with a realistic example that demonstrates that.

A way to turn off parallel execution (for easier comparison)

Would be neat if you could toggle the parallel execution on and off, to better demonstrate the performance difference that it implements.

Would happen in this code that calls gather():

asyncinject/asyncinject/__init__.py

Lines 114 to 123 in 4734897

	awaitables = [
	instance._registry[name](
	instance,
	_results=results,
	**{k: v for k, v in results.items() if k in instance._graph[name]},
	)
	for name in awaitable_names
	]
	awaitable_results = await asyncio.gather(*awaitables)
	results.update(dict(zip(awaitable_names, awaitable_results)))

Debug mechanism

Add a mechanism which shows exactly how the class is executing, including which methods are running in parallel. Maybe even with a very basic ASCII visualization? Then use it to help illustrate the examples in the README, refs #4.

Option to pass a dictionary with explicit names

I wanted to swap out the implementation of one of the functions based on other logic (to implement _shape= support in Datasette) - but asyncinject currently uses fn.__name__ introspection, which makes this hard to do.

Would be useful if you could optionally do this instead:

registry = Registry.from_dict({
    "both": both,
    "one": one,
    "two": two,
)

Using .from_dict() here so as not to have the Registry() constructor behave differently for different types of input.

Turn that visualization hack into a feature

Hack from:

• #10 (comment)

Tests and documentation showing what happens if something raises an Exception

Would it be possible to catch multiple exceptions from separate async tasks and group them together as a single group of exceptions raised by the resolve() method?

Concurrency is not being optimized

It looks like concurrency / parallelism is not being maximized due to the grouping of dependencies into node groups. Here's a simple example:

import asyncio
from time import time
from typing import Annotated

async def a():
    await asyncio.sleep(1)

async def b():
    await asyncio.sleep(2)

async def c(a):
    await asyncio.sleep(1)

async def d(b, c):
    pass

async def main_asyncinjector():
    reg = Registry(a, b, c, d)
    start = time()
    await reg.resolve(d)
    print(time()-start)

asyncio.run(main_asyncinjector())

This should take 2 seconds to run (start a and b, once a finishes start c, b and c finish at the same time and you're done) but takes 3 seconds (start a and b, wait for both to finish then start c).

This happens because graphlib.TopologicalSorter is not used online and instead it is being used to statically compute groups of dependencies.

I don't think it would be too hard to address this, but I'm not sure how much you'd want to change to accommodate this.
I work on a similar project (https://github.com/adriangb/di) and there I found it very useful to break out the concept of an "executor" out of the container/registry concept, which means that instead of a parallel option you'd have pluggable executors that could choose to use concurrency, limit concurrency, use threads instead, etc.
FWIW here's what that looks like with this example:

import asyncio
from time import time
from typing import Annotated

from asyncinject import Registry
from di.dependant import Marker, Dependant
from di.container import Container
from di.executors import ConcurrentAsyncExecutor


async def a():
    await asyncio.sleep(1)

async def b():
    await asyncio.sleep(2)

async def c(a: Annotated[None, Marker(a)]):
    await asyncio.sleep(1)

async def d(b: Annotated[None, Marker(b)], c: Annotated[None, Marker(c)]):
    pass

async def main_asyncinjector():
    reg = Registry(a, b, c, d)
    start = time()
    await reg.resolve(d)
    print(time()-start)


async def main_di():
    container = Container()
    solved = container.solve(Dependant(d), scopes=[None])
    executor = ConcurrentAsyncExecutor()
    async with container.enter_scope(None) as state:
        start = time()
        await container.execute_async(solved, executor, state=state)
        print(time()-start)

asyncio.run(main_asyncinjector())  # 3 seconds
asyncio.run(main_di())  # 2 seconds

Ignore parameters with default values

e.g. in this signature:

    @inject
    async def foo(bar, baz=1):
        # ...

Only bar should get the injection treatment. baz should be ignored.

Handle non-async functions too

It may be useful if this could also handle regular def ... functions, in addition to async def functions.

I'm imagining using this for Datasette extras where some extras might be able to operate directly on data that has already been fetched by other functions - e.g. an extra which transforms objects in some way.

Refs:

• simonw/datasette#262