This comment in #551 raised the concern about making it possible to use the instrumentors in a programmatic way too, not only automatically.

Using them programmatically means adding code directly in the application that performs instrumentation, for example, this or this.

It is very likely that this programmatic use of the instrumentors needs to be implemented in a framework-specific way, this means that the way we can do this kind of instrumentation is different for Flask and is different too for Django, for example. That means that it is possible that we end up having just special code for each framework as opposed to having a universal mechanism that works for every framework (this would mean that this issue could end up being closed without any fix).

This programmatic instrumentation mechanisms can be more sophisticated, for example, in an OpenTracing-related project here it is shown how the programmatic instrumentation mechanism allows the user to select which application functions are to be traced.

In summary, what we want to introduce with this issue, is the capability to perform instrumentation without having to directly write the code that creates the spans but also without using the opentelemetry-auto-instrumentation command, but with a different mechanism (probably specifically tailored for each framework (Django, Flask, etc.)) like decorators or maybe Python context managers (the ones that use with, to avoid any confusion with the OpenTelemetry concept of context 🙂).

@mauriciovasquezbernal @codeboten we have just talked about this 👍

Also, to make things clear, with this approach we would have 3 ways of doing instrumentation:

1. The "normal" way (instantiating the spans directly with OpenTelemetry-provided functions)
2. The automatic way (using the opentelemetry-auto-instrumentation command)
3. The programmatic way (using a mechanism as described here to instrument specific frameworks)