fix(docs): add TracerProvider setup to Django instrumentation example

[Copilot]

Description

Django instrumentation example was missing TracerProvider and SpanProcessor setup, so no traces were exported to console despite documentation claiming JSON span output would appear.

Changes:

• docs/examples/django/manage.py: Added TracerProvider + BatchSpanProcessor with ConsoleSpanExporter
• docs/examples/django/README.rst: Documented the required setup steps, aligned with Flask example pattern

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(ConsoleSpanExporter())
)
DjangoInstrumentor().instrument()

Fixes current_issue.md

Type of change

• Bug fix (non-breaking change which fixes an issue)
• This change requires a documentation update

How Has This Been Tested?

• tox -e ruff - all linting passed
• tox -e py312-test-opentelemetry-sdk - 636 tests passed
• Verified imports and TracerProvider setup executes correctly

Does This PR Require a Contrib Repo Change?

• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/open-telemetry/opentelemetry-python-contrib/commits/main
  • Triggering command: /home/REDACTED/.local/bin/uv /home/REDACTED/.local/bin/uv pip install git+REDACTED git+REDACTED git+REDACTED git+REDACTED git+REDACTED -r /home/REDACTED/work/opentelemetry-python/opentelemetry-python/docs/getting_started/tests/requirements.txt (http block)
• www.example.com
  • Triggering command: /home/REDACTED/work/opentelemetry-python/opentelemetry-python/.tox/py312-test-opentelemetry-getting-started/bin/python3 /home/REDACTED/work/opentelemetry-python/opentelemetry-python/.tox/py312-test-opentelemetry-getting-started/bin/python3 /home/REDACTED/work/opentelemetry-python/opentelemetry-python/docs/getting_started/tests/../flask_example.py (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Follow these instructions exactly and produce clear, verifiable outputs. The repository contains a file named CURRENT_ISSUE.md (case-insensitive: current_issue.md). That file describes the issue you must fix. Your mission is to:

1. Read the current_issue.md and fully understand the reported bug, failing test, or feature deficit. If the issue references specific files, tests, or behaviors, open and inspect those files. Assume you have read access to the repository working tree.
2. Design and implement a minimal, well-tested fix that resolves the issue while preserving intended behavior. If the fix requires changing multiple files, make coherent, focused commits.
3. Run the project's automated tests and linters locally. Use the project's recommended test command (search package.json, pyproject.toml, tox.ini, Makefile, or CONTRIBUTING.md). If no explicit command exists, use the conventional command for the language (e.g., pytest for Python). Ensure all tests pass before finishing.
4. Update or add documentation so that the repository README, relevant module docstrings, and any user-facing docs clearly describe the change and how to use the fixed behavior.
5. Create a file named fix_changelog.md at the repository root. In it, explain:
   • The problem (concise).
   • What changed (files, functions, configuration).
   • Why the change was made (root cause).
   • Tests added or updated.
   • Any backward compatibility considerations and migration steps if applicable.
6. Use the repository's pull_request_template.md located in .github/pull_request_template.md to generate a completed pull_request.md. Fill the template thoroughly: brief summary, testing steps performed, review notes, changelog cross-reference, and any security or performance considerations.
7. Follow repository contribution rules. Locate CONTRIBUTING.md (or docs/CONTRIBUTING.md). Respect branch naming conventions, commit message style, code style, and test coverage requirements specified. If the CONTRIBUTING document requires a specific header in commits, include it.
8. Use a clear branch name: fix/current-issue- or following repository convention. Commit in small logical steps with descriptive messages. Create at least one commit that contains the actual fix and one commit that contains documentation and changelog updates.
9. Provide a final patch summary in a file named fix_summary.txt at the repository root listing:
   • Files changed (with short diffs or descriptions).
   • Commands you ran to test and lint.
   • Test results (pass/fail and brief output).
   • Any remaining risks or follow-ups.
10. If the repository has a CI configuration (e.g., .github/workflows, .gitlab-ci.yml), ensure CI-related files are not accidentally broken. If the fix requires CI changes (e.g., to add a new test runner or environment variable), include them and document why.
11. Be conservative: prefer minimal, well-tested, readable changes over large refactors. Add comments explaining non-obvious behavior. Include type hints or types where appropriate.
    Acceptance criteria:

• All tests pass locally and reported in fix_summary.txt.
• fix_changelog.md clearly explains the fix.
• pull_request.md is generated from the PR template and filled completely.
• Documentation updated to avoid regressions.
• Changes follow CONTRIBUTING.md rules.
  Deliverables (files to create/update):
• Modified source files implementing the fix.
• Updated tests or new tests.
• Updated documentation files and README if relevant.
• fix_changelog.md
• pull_request.md (generated from pull_request_template.md)
• fix_summary.txt
• Git commits on a branch named per contributing conventions.
  Notes and constraints:
• Do not introduce heavy external dependencies. Prefer standard libraries or existing project dependencies.
• If the issue touches security-sensitive code, document the security reasoning in pull_request.md and fix_changelog.md.
• If you cannot determine the correct behavior from current_issue.md, make a best-effort safe change and document assumptions and rationale in fix_summary.txt and pull_request.md.
• If the repository uses multiple languages or services, limit changes to the minimum scope affecting current_issue.md.
• When running tests, capture output (stdout/stderr) in fix_summary.txt.
• The final pull_request.md should be human-readable and ready to paste into the repository.
  Use clear, conventional commit messages (feat/fix/docs/tests/chore) with a concise subject line limited to 72 characters, and a body explaining the rationale. If applicable, add or update type annotations and static type checks (mypy, typecheck) only where straightforward. When modifying public APIs, include deprecation notes for old behaviors and document replacement patterns. If new configuration options are introduced, validate inputs and provide sensible defaults and migration examples.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.