kuisathaverat / pytest_otel

pytest-otel plugin for reporting OpenTelemetry spans of tests executed.
Apache License 2.0
1 stars 0 forks source link

dotenv integration #68

Open codefromthecrypt opened 1 month ago

codefromthecrypt commented 1 month ago

Right now, I am not using pytest_otel, yet. I would like to be able to use a dotenv file to provide variables as opposed to launching pytest with dotenv.

Right now, I run tests like this, with opentelemetry-instrument, and I get spans for httpx calls, but not pytest. I would like to try this plugin.

uv run dotenv -f ./tests/otel.env run -- opentelemetry-instrument pytest tests -m integration {{FLAGS}}

./tests/otel.env

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_RESOURCE_ATTRIBUTES=service.name=MY_SERVICE
OTEL_METRIC_EXPORT_INTERVAL=100
OTEL_BSP_SCHEDULE_DELAY=100

Note: I have the following dev dependencies, which makes it incompatible with this plugin, as the dependencies here are strict ==

dev-dependencies = [
    "pytest>=8.3.2",
    "codecov>=2.1.13",
    "opentelemetry-sdk>=1.27.0",
    "opentelemetry-exporter-otlp-proto-http>=1.27.0",
    "opentelemetry-distro>=0.48b0",
    "opentelemetry-instrumentation-httpx>=0.48b0",
    "python-dotenv[cli]>=1.0.1"
]

I understand this is a combination of a feature request (dotenv support) and dependency leniency (something besides ==), so if you want this split up I can do that.

codefromthecrypt commented 1 month ago

suggestion for the revlock problem is to change the deps here to >= instead of == and not increment it on every patch. That will give downstream users the flexibility to use later versions of whatever or delay upgrading depending on what happens here. my 2p

kuisathaverat commented 1 month ago

Note: I have the following dev dependencies, which makes it incompatible with this plugin, as the dependencies here are strict suggestion for the revlock problem is to change the deps here to >= instead of == and not increment it on every patch. That will give downstream users the flexibility to use later versions of whatever or delay upgrading depending on what happens here. my 2p

I preferred to keep dependencies strict to avoid compatibility issues, and ensure replicability.

kuisathaverat commented 1 month ago

For the dotenv support, you can use your shell capabilities as a workaround.

source ./tests/otel.env
uv run dotenv -f ./tests/otel.env run -- opentelemetry-instrument pytest tests -m integration {{FLAGS}}

I will add a flag to allow passing a dotenv file.

codefromthecrypt commented 1 month ago

I preferred to keep dependencies strict to avoid compatibility issues, and ensure replicability.

I understand what you are aiming at, but doing so makes conflicts downstream. most notably the pytest version. This may limit adoption even if it achieves what you mention. I'm not arguing, just saying because I don't think I can use it due to this, even if others can match versions with you whenever a release occurs.