internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: jazzband/django-debug-toolbar

Issue:
Issue importing settings since 3.2.3
Hello! I have a Django project in which I import the `PANELS_DEFAULTS` into the settings, modify it, and use it for `DEBUG_TOOLBAR_PANELS`. This simplifies the removal of any particular panel, as the defaults don't need to be hard-coded in our settings.

However, as of djdt 3.2.3, this no longer works. The following line in our `settings.py` file causes an `AppRegistryNotReady` error:
```python
from debug_toolbar.settings import PANELS_DEFAULTS
```
If we change it to `import debug_toolbar`, I see an `ImproperlyConfigured` error related to missing `SECRET_KEY`.

I think this is because as of 3.2.3, `debug_toolbar/__init__.py` imports `app_name`, which ultimately imports the whole package. And perhaps that's not good to do that in a `settings.py` file. It might be that we can restructure our `settings.py` to make this work, but at the moment I'm guessing not.

Would it be possible to restructure things such that `debug_toolbar.settings` could be imported without triggering the import of other submodules? Perhaps put `app_name` by itself in a module that itself doesn't import anything? I'm happy to task a stab at this if someone indicates that it would be acceptable.

Or perhaps is there a different approach to "modifying" the default panel settings?



Discussion:

Resolving patch:
diff --git a/debug_toolbar/__init__.py b/debug_toolbar/__init__.py
--- a/debug_toolbar/__init__.py
+++ b/debug_toolbar/__init__.py
@@ -1,12 +1,8 @@
-from debug_toolbar.urls import app_name
-
 __all__ = ["VERSION"]
 
-
 # Do not use pkg_resources to find the version but set it here directly!
 # see issue #1446
 VERSION = "3.2.4"
 
 # Code that discovers files or modules in INSTALLED_APPS imports this module.
-
-urls = "debug_toolbar.urls", app_name
+urls = "debug_toolbar.urls", "djdt"  # See debug_toolbar/urls.py
diff --git a/debug_toolbar/urls.py b/debug_toolbar/urls.py
--- a/debug_toolbar/urls.py
+++ b/debug_toolbar/urls.py
@@ -1,4 +1,4 @@
 from debug_toolbar.toolbar import DebugToolbar
 
-app_name = "djdt"
+app_name = "djdt"  # See debug_toolbar/__init__.py
 urlpatterns = DebugToolbar.get_urls()


Test patch:
Repository: jazzband/django-debug-toolbar

Issue:
The STATICFILES_STORAGE setting is deprecated in Django 4.2
The _Static files_ panel produces the following warning in Django 4.2

`RemovedInDjango51Warning: The STATICFILES_STORAGE setting is deprecated. Use STORAGES instead.`

This is due to the use of the `django.core.files.storage.get_storage_class()` function which has been deprecated.

I will submit a patch and pull request to resolve this issue.


Discussion:

Resolving patch:
diff --git a/debug_toolbar/panels/staticfiles.py b/debug_toolbar/panels/staticfiles.py
--- a/debug_toolbar/panels/staticfiles.py
+++ b/debug_toolbar/panels/staticfiles.py
@@ -3,7 +3,6 @@
 from django.conf import settings
 from django.contrib.staticfiles import finders, storage
 from django.core.checks import Warning
-from django.core.files.storage import get_storage_class
 from django.utils.functional import LazyObject
 from django.utils.translation import gettext_lazy as _, ngettext
 
@@ -53,7 +52,17 @@ class DebugConfiguredStorage(LazyObject):
     """
 
     def _setup(self):
-        configured_storage_cls = get_storage_class(settings.STATICFILES_STORAGE)
+        try:
+            # From Django 4.2 use django.core.files.storage.storages in favor
+            # of the deprecated django.core.files.storage.get_storage_class
+            from django.core.files.storage import storages
+
+            configured_storage_cls = storages["staticfiles"].__class__
+        except ImportError:
+            # Backwards compatibility for Django versions prior to 4.2
+            from django.core.files.storage import get_storage_class
+
+            configured_storage_cls = get_storage_class(settings.STATICFILES_STORAGE)
 
         class DebugStaticFilesStorage(configured_storage_cls):
             def __init__(self, collector, *args, **kwargs):


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
EC2 resource detector hangs for a long time outside of an EC2 instance
**Describe your environment** Describe any aspect of your environment relevant to the problem, including your Python version, [platform](https://docs.python.org/3/library/platform.html), version numbers of installed dependencies, information about your cloud hosting provider, etc. If you're reporting a problem with a specific version of a library in this repo, please check whether the problem has been fixed on main.

The environment I initially saw this in was a container running in Docker compose on an AWS EC2 instance but I've been able to reproduce it on my laptop as well. I think it will show up in anything not directly running in AWS.

**Steps to reproduce**
Describe exactly how to reproduce the error. Include a code sample if applicable.

The following code reproduced the issue on my laptop:

```python
from opentelemetry.sdk.extension.aws.resource.ec2 import AwsEc2ResourceDetector
from opentelemetry.sdk.resources import get_aggregated_resources

resource = get_aggregated_resources(
    detectors=[AwsEc2ResourceDetector()]
)
```

**What is the expected behavior?**

It should complete quickly (this is the behavior I see running on an EC2 instance).

**What is the actual behavior?**

What did you see instead?

On my laptop, it will hand ~indefinitely.

Note: one solution is just to remove the resource detector but we'd like to be able to include it and just have it fail silently, which is the behavior we've seen in other resource detectors.

**Additional context**

I think the problem is here: https://github.com/open-telemetry/opentelemetry-python-contrib/blob/80969a06da77d1e616124de178d12a1ebe3ffe7f/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/resource/ec2.py#L37

It looks like the request is using a 1000 _second_ timeout which I suspect is intended to be a 1000 _millisecond_ timeout. At least with the server program I've been working on that will block the startup of the program until the request completes.

You can verify by running:

```
curl http://169.254.169.254/latest/api/token
```

Which is one of the requests that the resource detector makes -- it should hang indefinitely as well.



Discussion:

Resolving patch:
diff --git a/instrumentation/opentelemetry-instrumentation-botocore/src/opentelemetry/instrumentation/botocore/version.py b/instrumentation/opentelemetry-instrumentation-botocore/src/opentelemetry/instrumentation/botocore/version.py
--- a/instrumentation/opentelemetry-instrumentation-botocore/src/opentelemetry/instrumentation/botocore/version.py
+++ b/instrumentation/opentelemetry-instrumentation-botocore/src/opentelemetry/instrumentation/botocore/version.py
@@ -12,4 +12,4 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-__version__ = "0.15.dev0"
+__version__ = "0.15b0"


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
Remove unused import
As per comment https://github.com/open-telemetry/opentelemetry-python-contrib/pull/107#discussion_r516262746, there appears to be an unused import in the jinja2 instrumentation


Discussion:
Hello, Is this issue still open and can I please work on it?

Resolving patch:
diff --git a/instrumentation/opentelemetry-instrumentation-jinja2/src/opentelemetry/instrumentation/jinja2/__init__.py b/instrumentation/opentelemetry-instrumentation-jinja2/src/opentelemetry/instrumentation/jinja2/__init__.py
--- a/instrumentation/opentelemetry-instrumentation-jinja2/src/opentelemetry/instrumentation/jinja2/__init__.py
+++ b/instrumentation/opentelemetry-instrumentation-jinja2/src/opentelemetry/instrumentation/jinja2/__init__.py
@@ -52,7 +52,6 @@
 from opentelemetry.instrumentation.jinja2.version import __version__
 from opentelemetry.instrumentation.utils import unwrap
 from opentelemetry.trace import SpanKind, get_tracer
-from opentelemetry.trace.status import Status, StatusCode
 
 logger = logging.getLogger(__name__)
 


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
Add database_index attribute for redis instrumentation when db is not 0
Prior discussion [here](https://github.com/open-telemetry/opentelemetry-python-contrib/pull/184#discussion_r528913282).

The spec says for redis if db is not 0 it should have `db.redis.database_index` set to the index of the database being accessed as used in the SELECT command, provided as an integer.


Discussion:

Resolving patch:
diff --git a/instrumentation/opentelemetry-instrumentation-redis/src/opentelemetry/instrumentation/redis/util.py b/instrumentation/opentelemetry-instrumentation-redis/src/opentelemetry/instrumentation/redis/util.py
--- a/instrumentation/opentelemetry-instrumentation-redis/src/opentelemetry/instrumentation/redis/util.py
+++ b/instrumentation/opentelemetry-instrumentation-redis/src/opentelemetry/instrumentation/redis/util.py
@@ -21,8 +21,10 @@ def _extract_conn_attributes(conn_kwargs):
     """ Transform redis conn info into dict """
     attributes = {
         "db.system": "redis",
-        "db.name": conn_kwargs.get("db", 0),
     }
+    db = conn_kwargs.get("db", 0)
+    attributes["db.name"] = db
+    attributes["db.redis.database_index"] = db
     try:
         attributes["net.peer.name"] = conn_kwargs["host"]
         attributes["net.peer.ip"] = conn_kwargs["port"]


Test patch:
diff --git a/tests/opentelemetry-docker-tests/tests/redis/test_redis_functional.py b/tests/opentelemetry-docker-tests/tests/redis/test_redis_functional.py
--- a/tests/opentelemetry-docker-tests/tests/redis/test_redis_functional.py
+++ b/tests/opentelemetry-docker-tests/tests/redis/test_redis_functional.py
@@ -115,3 +115,30 @@ def test_parent(self):
             child_span.attributes.get("service"), self.test_service
         )
         self.assertEqual(child_span.name, "GET")
+
+
+class TestRedisDBIndexInstrument(TestBase):
+    def setUp(self):
+        super().setUp()
+        self.redis_client = redis.Redis(port=6379, db=10)
+        self.redis_client.flushall()
+        RedisInstrumentor().instrument(tracer_provider=self.tracer_provider)
+
+    def tearDown(self):
+        super().tearDown()
+        RedisInstrumentor().uninstrument()
+
+    def _check_span(self, span, name):
+        self.assertEqual(span.name, name)
+        self.assertIs(span.status.status_code, trace.status.StatusCode.UNSET)
+        self.assertEqual(span.attributes["net.peer.name"], "localhost")
+        self.assertEqual(span.attributes["net.peer.ip"], 6379)
+        self.assertEqual(span.attributes["db.redis.database_index"], 10)
+
+    def test_get(self):
+        self.assertIsNone(self.redis_client.get("foo"))
+        spans = self.memory_exporter.get_finished_spans()
+        self.assertEqual(len(spans), 1)
+        span = spans[0]
+        self._check_span(span, "GET")
+        self.assertEqual(span.attributes.get("db.statement"), "GET foo")
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
Allow to modify the computed Span name via callback.
# Description

With Redis and Databases in a traces, there is no easy way from the span name to see if a "SELECT" is going to Redis or the database.


## Type of change

Please delete options that are not relevant.

- [X] New feature (non-breaking change which adds functionality)

# How Has This Been Tested?

- [X] TestRedis::test_name_callback

# Does This PR Require a Core Repo Change?

- [ ] Yes. - Link to PR: 
- [X] No.

# Checklist:

See [contributing.md](https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/CONTRIBUTING.md) for styleguide, changelog guidelines, and more.

- [?] Followed the style guidelines of this project
- [X] Changelogs have been updated
- [X] Unit tests have been added
- [X] Documentation has been updated



Discussion:

Resolving patch:
diff --git a/instrumentation/opentelemetry-instrumentation-requests/src/opentelemetry/instrumentation/requests/__init__.py b/instrumentation/opentelemetry-instrumentation-requests/src/opentelemetry/instrumentation/requests/__init__.py
--- a/instrumentation/opentelemetry-instrumentation-requests/src/opentelemetry/instrumentation/requests/__init__.py
+++ b/instrumentation/opentelemetry-instrumentation-requests/src/opentelemetry/instrumentation/requests/__init__.py
@@ -25,7 +25,7 @@
     import opentelemetry.instrumentation.requests
 
     # You can optionally pass a custom TracerProvider to
-    # RequestInstrumentor.instrument()
+    # RequestsInstrumentor.instrument()
     opentelemetry.instrumentation.requests.RequestsInstrumentor().instrument()
     response = requests.get(url="https://www.example.org/")
 


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
Add fields property
This issue is opened here because its fix it is needed here to address [this](https://github.com/open-telemetry/opentelemetry-python/pull/1374) issue.


Discussion:

Resolving patch:
diff --git a/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/propagator.py b/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/propagator.py
--- a/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/propagator.py
+++ b/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/propagator.py
@@ -106,6 +106,19 @@ def inject(
                 span.context.trace_state[constants.DD_ORIGIN],
             )
 
+    def fields(self):
+        """Returns a set with the fields set in `inject`.
+
+        See
+        `opentelemetry.trace.propagation.textmap.TextMapPropagator.fields`
+        """
+        return {
+            self.TRACE_ID_KEY,
+            self.PARENT_ID_KEY,
+            self.SAMPLING_PRIORITY_KEY,
+            self.ORIGIN_KEY,
+        }
+
 
 def format_trace_id(trace_id: int) -> str:
     """Format the trace id for Datadog."""
diff --git a/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py b/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py
--- a/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py
+++ b/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py
@@ -274,3 +274,12 @@ def inject(
         set_in_carrier(
             carrier, TRACE_HEADER_KEY, trace_header,
         )
+
+    def fields(self):
+        """Returns a set with the fields set in `inject`.
+
+        See
+        `opentelemetry.trace.propagation.textmap.TextMapPropagator.fields`
+        """
+
+        return {TRACE_HEADER_KEY}


Test patch:
diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -6,7 +6,7 @@ on:
     - 'release/*'
   pull_request:
 env:
-  CORE_REPO_SHA: bce2aa649c9f3541a57b115ceb6694c5a00ca856
+  CORE_REPO_SHA: 5de7ffd7cbb555fb04d0138361a188496557080d
 
 jobs:
   build:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
Fix readthedocs build
As discussed in 01/28/2021 SIG.


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -124,8 +124,8 @@ def getlistcfg(strval):
 
 if "anys" in mcfg:
     anys = getlistcfg(mcfg["anys"])
-    for any in anys:
-        nitpick_ignore.append(("any", any,))
+    for _any in anys:
+        nitpick_ignore.append(("any", _any,))
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ["_templates"]


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
exporter-datadog: docstring does not match arguments
The docstring here:
https://github.com/open-telemetry/opentelemetry-python-contrib/blob/master/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py#L68
says it expects a list, but what it really expects is a string containing a comma-separated list of tags.

Do I fix the docstring, do I change the code code to accept a real list ,or do I change the code to accept *either* a list or the current string?  I'm also working on #154 and would really prefer both objects accept the same parameters if possible.. but this is just odd, and IMHO not very pythonic.

What do we prefer for things like this?

(I'm happy to do the work, again, since I'm already working on related stuff)


Discussion:
@alertedsnake 
I would simply change the docstring to reflect the actual code.
This issue was marked stale due to lack of activity. It will be closed in 30 days.

Resolving patch:
diff --git a/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py b/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py
--- a/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py
+++ b/exporter/opentelemetry-exporter-datadog/src/opentelemetry/exporter/datadog/exporter.py
@@ -63,7 +63,7 @@ class DatadogSpanExporter(SpanExporter):
         service: The service name to be used for the application or use ``DD_SERVICE`` environment variable
         env: Set the application’s environment or use ``DD_ENV`` environment variable
         version: Set the application’s version or use ``DD_VERSION`` environment variable
-        tags: A list of default tags to be added to every span or use ``DD_TAGS`` environment variable
+        tags: A list (formatted as a comma-separated string) of default tags to be added to every span or use ``DD_TAGS`` environment variable
     """
 
     def __init__(


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
Compatible with web.py?
Is it possible to use  opentelemetry-insrumentation-wsgi with web.py framework? If yes, some examples would be appreciated.


Discussion:
Does this help https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/wsgi/wsgi.html?

Resolving patch:
diff --git a/instrumentation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py b/instrumentation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
--- a/instrumentation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
+++ b/instrumentation/opentelemetry-instrumentation-wsgi/src/opentelemetry/instrumentation/wsgi/__init__.py
@@ -13,7 +13,7 @@
 # limitations under the License.
 """
 This library provides a WSGI middleware that can be used on any WSGI framework
-(such as Django / Flask) to track requests timing through OpenTelemetry.
+(such as Django / Flask / Web.py) to track requests timing through OpenTelemetry.
 
 Usage (Flask)
 -------------
@@ -50,6 +50,35 @@ def hello():
     application = get_wsgi_application()
     application = OpenTelemetryMiddleware(application)
 
+Usage (Web.py)
+--------------
+
+.. code-block:: python
+
+    import web
+    from opentelemetry.instrumentation.wsgi import OpenTelemetryMiddleware
+    from cheroot import wsgi
+
+    urls = ('/', 'index')
+
+
+    class index:
+
+        def GET(self):
+            return "Hello, world!"
+
+
+    if __name__ == "__main__":
+        app = web.application(urls, globals())
+        func = app.wsgifunc()
+
+        func = OpenTelemetryMiddleware(func)
+
+        server = wsgi.WSGIServer(
+            ("localhost", 5100), func, server_name="localhost"
+        )
+        server.start()
+
 API
 ---
 """


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
psycopg2-binary dependency conflict
**Describe your environment** 
```
> pip freeze | grep psyco
opentelemetry-instrumentation-psycopg2==0.22b0
psycopg2==2.8.6
```

**Steps to reproduce**
Install `psycopg2` instead of `psycopg2-binary`

**What is the expected behavior?**
No error message popping up

**What is the actual behavior?**
The instrumentation library will throw this error for every run.
```
DependencyConflict: requested: "psycopg2-binary >= 2.7.3.1" but found: "None"
```

**Additional context**
The instrumentation actually works as expected for `psycopg2`. So, the package instrumented should be both `psycopg2-binary` and `psycopg`



Discussion:
`psycopg-binary` is not recommended for production usage. It should not be used as a dependency in general. It is more of a workaround for local setups.

Resolving patch:
diff --git a/instrumentation/opentelemetry-instrumentation-psycopg2/src/opentelemetry/instrumentation/psycopg2/package.py b/instrumentation/opentelemetry-instrumentation-psycopg2/src/opentelemetry/instrumentation/psycopg2/package.py
--- a/instrumentation/opentelemetry-instrumentation-psycopg2/src/opentelemetry/instrumentation/psycopg2/package.py
+++ b/instrumentation/opentelemetry-instrumentation-psycopg2/src/opentelemetry/instrumentation/psycopg2/package.py
@@ -13,4 +13,4 @@
 # limitations under the License.
 
 
-_instruments = ("psycopg2-binary >= 2.7.3.1",)
+_instruments = ("psycopg2 >= 2.7.3.1",)
diff --git a/opentelemetry-instrumentation/src/opentelemetry/instrumentation/bootstrap_gen.py b/opentelemetry-instrumentation/src/opentelemetry/instrumentation/bootstrap_gen.py
--- a/opentelemetry-instrumentation/src/opentelemetry/instrumentation/bootstrap_gen.py
+++ b/opentelemetry-instrumentation/src/opentelemetry/instrumentation/bootstrap_gen.py
@@ -80,8 +80,8 @@
         "library": "mysql-connector-python ~= 8.0",
         "instrumentation": "opentelemetry-instrumentation-mysql==0.23.dev0",
     },
-    "psycopg2-binary": {
-        "library": "psycopg2-binary >= 2.7.3.1",
+    "psycopg2": {
+        "library": "psycopg2 >= 2.7.3.1",
         "instrumentation": "opentelemetry-instrumentation-psycopg2==0.23.dev0",
     },
     "pymemcache": {


Test patch:
Repository: open-telemetry/opentelemetry-python-contrib

Issue:
AWS X-Ray propagator should be registered with xray environment variable
In the spec, we have a definition for the environment variable as `xray`

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#general-sdk-configuration

Currently python uses `aws_xray`


Discussion:
/cc @NathanielRN 

Resolving patch:
diff --git a/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py b/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py
--- a/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py
+++ b/sdk-extension/opentelemetry-sdk-extension-aws/src/opentelemetry/sdk/extension/aws/trace/propagation/aws_xray_format.py
@@ -31,7 +31,7 @@
 
 ::
 
-    export OTEL_PROPAGATORS = aws_xray
+    export OTEL_PROPAGATORS = xray
 
 
 Or by setting this propagator in your instrumented application:


Test patch: