internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: django-crispy-forms/django-crispy-forms

Issue:
Byte-compiled files in tarball
Difio found some byte-compiled files in the latest tarball. Looks suspicious:

crispy_forms/tests/test_settings_bootstrap.pyc : python 2.7 byte-compiled
crispy_forms/tests/**init**.pyc : python 2.7 byte-compiled
crispy_forms/tests/test_settings_uniform.pyc : python 2.7 byte-compiled
crispy_forms/tests/urls.pyc : python 2.7 byte-compiled
crispy_forms/tests/forms.pyc : python 2.7 byte-compiled
crispy_forms/tests/utils.pyc : python 2.7 byte-compiled
crispy_forms/tests/**pycache**/test_settings_bootstrap.cpython-32.pyc : python 3.2 byte-compiled
crispy_forms/tests/**pycache**/**init**.cpython-32.pyc : python 3.2 byte-compiled
crispy_forms/tests/tests.pyc : python 2.7 byte-compiled



Discussion:
This is likely due to this:
https://github.com/maraujop/django-crispy-forms/blob/dev/MANIFEST.in#L7

I needed to include tests recursively when installing django-crispy-forms, but those pyc shouldn't be there if I'm not mistaken. Not sure how to fix it.

Cheers,
Miguel


Resolving patch:
diff --git a/crispy_forms/__init__.py b/crispy_forms/__init__.py
--- a/crispy_forms/__init__.py
+++ b/crispy_forms/__init__.py
@@ -1,3 +1,3 @@
 # -*- coding: utf-8 -*-
 
-__version__ = '1.5.1'
+__version__ = '1.5.2'
diff --git a/crispy_forms/base.py b/crispy_forms/base.py
--- a/crispy_forms/base.py
+++ b/crispy_forms/base.py
@@ -19,4 +19,5 @@ def __enter__(self):
 
     def __exit__(self, type, value, traceback):
         for key in list(self.keys):
-            del self.context[key]
+            if key in self.context:
+                del self.context[key]


Test patch:
Repository: django-crispy-forms/django-crispy-forms

Issue:
Allow using variables from context processor inside form templates
Currently if you try to override the `crispy_forms` templates and use something like `{{ request }}` it can't really find the request.



Discussion:

Resolving patch:
diff --git a/crispy_forms/templatetags/crispy_forms_tags.py b/crispy_forms/templatetags/crispy_forms_tags.py
--- a/crispy_forms/templatetags/crispy_forms_tags.py
+++ b/crispy_forms/templatetags/crispy_forms_tags.py
@@ -126,6 +126,7 @@ def get_render(self, context):
         response_dict = self.get_response_dict(helper, context, is_formset)
         node_context = copy_context(context)
         node_context.update(response_dict)
+        final_context = copy_context(node_context)
 
         # If we have a helper's layout we use it, for the form or the formset's forms
         if helper and helper.layout:
@@ -140,11 +141,11 @@ def get_render(self, context):
                     forloop.iterate()
 
         if is_formset:
-            response_dict.update({'formset': actual_form})
+            final_context['formset'] = actual_form
         else:
-            response_dict.update({'form': actual_form})
+            final_context['form'] = actual_form
 
-        return Context(response_dict)
+        return final_context
 
     def get_response_dict(self, helper, context, is_formset):
         """


Test patch:
diff --git a/crispy_forms/tests/templates/custom_form_template_with_context.html b/crispy_forms/tests/templates/custom_form_template_with_context.html
new file mode 100644
--- /dev/null
+++ b/crispy_forms/tests/templates/custom_form_template_with_context.html
@@ -0,0 +1,4 @@
+<h1>Special custom form with context passthrough</h1>
+Got prefix: {{ prefix }}.
+{% include "bootstrap/whole_uni_form.html" %}
+Got suffix: {{ suffix }}.
diff --git a/crispy_forms/tests/test_form_helper.py b/crispy_forms/tests/test_form_helper.py
--- a/crispy_forms/tests/test_form_helper.py
+++ b/crispy_forms/tests/test_form_helper.py
@@ -722,3 +722,22 @@ def test_bootstrap4_template_pack():
     html = render_crispy_form(form)
     assert 'form-control' not in html
     assert 'ctrlHolder' in html
+
+
+def test_passthrough_context():
+    """
+    Test to ensure that context is passed through implicitly from outside of
+    the crispy form into the crispy form templates.
+    """
+    form = TestForm()
+    form.helper = FormHelper()
+    form.helper.template = 'custom_form_template_with_context.html'
+
+    c = {
+        'prefix': 'foo',
+        'suffix': 'bar'
+    }
+
+    html = render_crispy_form(form, helper=form.helper, context=c)
+    assert "Got prefix: foo" in html
+    assert "Got suffix: bar" in html
Repository: django-crispy-forms/django-crispy-forms

Issue:
added label_class and field_class to the as_crispy_field filter
To clean up my templates I've been using [`string_if_invalid`](http://stackoverflow.com/a/33750585/1888983). Not having `label_class` or `field_class` defined in `field.html` was causing the `string_if_invalid` to be printed. I've duplicated the extra arguments from `as_crispy_form` to `as_crispy_field` with default empty strings to fix this problem.



Discussion:

Resolving patch:
diff --git a/crispy_forms/templatetags/crispy_forms_filters.py b/crispy_forms/templatetags/crispy_forms_filters.py
--- a/crispy_forms/templatetags/crispy_forms_filters.py
+++ b/crispy_forms/templatetags/crispy_forms_filters.py
@@ -89,7 +89,7 @@ def as_crispy_errors(form, template_pack=TEMPLATE_PACK):
 
 
 @register.filter(name='as_crispy_field')
-def as_crispy_field(field, template_pack=TEMPLATE_PACK):
+def as_crispy_field(field, template_pack=TEMPLATE_PACK, label_class="", field_class=""):
     """
     Renders a form field like a django-crispy-forms field::
 
@@ -104,8 +104,13 @@ def as_crispy_field(field, template_pack=TEMPLATE_PACK):
         raise CrispyError('|as_crispy_field got passed an invalid or inexistent field')
 
     template = get_template('%s/field.html' % template_pack)
-    c = Context({'field': field, 'form_show_errors': True, 'form_show_labels': True}).flatten()
-
+    c = Context({
+        'field': field,
+        'form_show_errors': True,
+        'form_show_labels': True,
+        'label_class': label_class,
+        'field_class': field_class,
+        }).flatten()
     return template.render(c)
 
 


Test patch:
Repository: django-crispy-forms/django-crispy-forms

Issue:
Use helper of field form in `as_crispy_field` filter.
While trying to satisfy my usecase i stumbled upon [this](https://github.com/maraujop/django-crispy-forms/issues/96) issue where @rafalp expressed desire to be able to use helpers with `as_crispy_field` filter. Two years later here i am implementing this functionality. It also uses `helper.field_template` if one is set.



Discussion:

Resolving patch:
diff --git a/crispy_forms/templatetags/crispy_forms_filters.py b/crispy_forms/templatetags/crispy_forms_filters.py
--- a/crispy_forms/templatetags/crispy_forms_filters.py
+++ b/crispy_forms/templatetags/crispy_forms_filters.py
@@ -103,14 +103,24 @@ def as_crispy_field(field, template_pack=TEMPLATE_PACK, label_class="", field_cl
     if not isinstance(field, forms.BoundField) and settings.DEBUG:
         raise CrispyError('|as_crispy_field got passed an invalid or inexistent field')
 
-    template = get_template('%s/field.html' % template_pack)
-    c = Context({
+    attributes = {
         'field': field,
         'form_show_errors': True,
         'form_show_labels': True,
         'label_class': label_class,
         'field_class': field_class,
-        }).flatten()
+    }
+    helper = getattr(field.form, 'helper', None)
+
+    template_path = None
+    if helper is not None:
+        attributes.update(helper.get_attributes(template_pack))
+        template_path = helper.field_template
+    if not template_path:
+        template_path = '%s/field.html' % template_pack
+    template = get_template(template_path)
+
+    c = Context(attributes).flatten()
     return template.render(c)
 
 


Test patch:
Repository: django-crispy-forms/django-crispy-forms

Issue:
v1.8 shortlist
Hi @carltongibson ,

I thought I'd put together a shortlist for the 1.8 release. I think there are a few 'easy' issues that could be closed. 

- [x] Review #899 fixes #798 
- [x] Re-work #868 to extract fix for #861 
- [x] Review #881 fixes #859 
- [x] Investigate #793 as we have looked at this code recently, #794 also did some work. 
- [x] #904 would be nice, but only if @Gilbishkosma has time. 

The other thing I was going to put on the list was about reviewing / updating the docs. I notice that RTD doesn't seem that up to date so I may be looking in the wrong place? 


Therefore key changes in 1.8 are:

1. Django 3.0 compatibility
2. Various improvements to BS4. (Incl. File field, error labels and xl size)

Hope this is helpful!? Anything else you think is missing? 


Discussion:
@smithdc1  sure , i will see the #904 
Hey @smithdc1. I ticked off a couple. I will look at Django 3.0 compat (I think we're there already really…). Then we're not far off. Thanks for your input! 
Thanks Carlon.

I've had a look at the second item on the list. Having tried to reproduce the issue it looks like it's already been fixed, I've therefore closed the issue and the related PR (hope this is ok!). There is still something in the way `label=false` renders for booleans but I don't there is a use case for boolean without a label and I've not come across an issue raised for this. 

Another step closer 😃 
Hi! Any idea for the timing of the 1.8 release? It's been ~1.5 years since the last one and there are a few fixes that'd be nice to have as an official release 🚀 
Hi @myartsev, we are close. I closed off the 4th item on the list over the weekend so just one task remaining (which _I think_ is a nice to have)
@carltongibson is there anything else we need to do (or that I can help with?) before the next release? 

Resolving patch:
diff --git a/crispy_forms/__init__.py b/crispy_forms/__init__.py
--- a/crispy_forms/__init__.py
+++ b/crispy_forms/__init__.py
@@ -1,3 +1,3 @@
 # -*- coding: utf-8 -*-
 
-__version__ = '1.7.2'
+__version__ = '1.8.0'
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -29,9 +29,9 @@
         "Environment :: Web Environment",
         "Framework :: Django",
         "Framework :: Django :: 1.11",
-        "Framework :: Django :: 2.0",
         "Framework :: Django :: 2.1",
-        "Framework :: Django :: 2.2",        
+        "Framework :: Django :: 2.2",
+        "Framework :: Django :: 3.0",
         "License :: OSI Approved :: MIT License",
         "Operating System :: OS Independent",
         "Programming Language :: JavaScript",


Test patch:
Repository: django-crispy-forms/django-crispy-forms

Issue:
Specify Python version requirement (>=3.x)
https://github.com/django-crispy-forms/django-crispy-forms/blob/ba53410f752402436d84dc8ab00e2b6e1e67a74c/setup.py#L22

The drop of Python 2 support in release 1.9.0 has broken installation of the package for users of Python 2 because it does not specify that Python 3 is required.

The recommendation is specified here, including instructions for `setup.py`: 
https://packaging.python.org/guides/dropping-older-python-versions/

Would you mind adding the specification to the package?
This would also mean either re-releasing 1.9.0 :see_no_evil:  or update 1.9.0 directly in Pypi with that information (is it possible?) or releasing something like 1.9.0.1 or 1.9.1 and removing 1.9.0 from Pypi...


Discussion:
Happy to take a PR adding it for the next release. TBH not prepared to pull a release from PyPI that folks could/should have pinned to. 

If you're still on Python 2, just pin to 1.8.x. 

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -50,4 +50,5 @@
     packages=find_packages(exclude=['docs']),
     include_package_data=True,
     zip_safe=False,
+    python_requires='>=3.5',
 )


Test patch:
Repository: django-crispy-forms/django-crispy-forms

Issue:
Allow Fieldset to accept Fields
* Package version: 2.0
* Django version: 3.2.18
* Python version: 3.8.17
* Template pack: crispy-bootstrap5 0.7

### Description:

The `Fieldset` class accepts a number of fields to render in a `<fieldset>`. Apparently, the value of this field can only be `str`:

https://github.com/django-crispy-forms/django-crispy-forms/blob/3b81cc98f99505cd55a7fdc7cb7ca2744f6e2546/crispy_forms/layout.py#L521

This causes a type checking error if one uses `Field` and any subclasses of it, like `AppendedText` from the Bootstrap pack.

I propose changing the type of the kwargs to `str | LayoutObject`


Discussion:

Resolving patch:
diff --git a/crispy_forms/layout.py b/crispy_forms/layout.py
--- a/crispy_forms/layout.py
+++ b/crispy_forms/layout.py
@@ -518,7 +518,7 @@ class Fieldset(LayoutObject):
     legend : str
         The content of the fieldset's ``<legend>``. This text is context
         aware, to bring this to life see the examples section.
-    *fields : str
+    *fields : str | LayoutObject | HTML
         Any number of fields as positional arguments to be rendered within
         the ``<fieldset>``
     css_class : str, optional


Test patch:
Repository: getsentry/sentry-python

Issue:
Breadcrumbs type error
We're having an issue with v0.3.2 where `popleft` is called on a list type:

```
File "/srv/frontend/project/lib/python3.5/site-packages/sentry_sdk/hub.py" in add_breadcrumb
  209.             scope._breadcrumbs.popleft()

Exception Type: AttributeError at /
Exception Value: 'list' object has no attribute 'popleft'
```


Discussion:
Getting this issue as well with v0.3.0. It is occurring for me when I run `collectstatic` as part of the deployment of a Django application, during the cross-loading of static files to S3 using `boto`.

Resolving patch:
diff --git a/sentry_sdk/hub.py b/sentry_sdk/hub.py
--- a/sentry_sdk/hub.py
+++ b/sentry_sdk/hub.py
@@ -205,8 +205,8 @@ def add_breadcrumb(self, crumb=None, hint=None, **kwargs):
             scope._breadcrumbs.append(crumb)
         else:
             logger.info("before breadcrumb dropped breadcrumb (%s)", original_crumb)
-        while len(scope._breadcrumbs) >= client.options["max_breadcrumbs"]:
-            scope._breadcrumbs.popleft()
+        while len(scope._breadcrumbs) > client.options["max_breadcrumbs"]:
+            scope._breadcrumbs.pop(0)
 
     def push_scope(self, callback=None):
         """Pushes a new layer on the scope stack. Returns a context manager


Test patch:
diff --git a/tests/test_basics.py b/tests/test_basics.py
--- a/tests/test_basics.py
+++ b/tests/test_basics.py
@@ -139,3 +139,20 @@ def test_push_scope_null_client(sentry_init, capture_events):
             capture_exception(e)
 
     assert len(events) == 0
+
+
+def test_breadcrumbs_overflow(sentry_init, capture_events):
+    sentry_init(max_breadcrumbs=10)
+
+    for i in range(20):
+        add_breadcrumb(
+            category="auth", message="Authenticated user %s" % i, level="info"
+        )
+
+    events = capture_events()
+
+    capture_exception(ValueError())
+
+    event, = events
+
+    assert len(event["breadcrumbs"]) == 10
Repository: getsentry/sentry-python

Issue:
Rename meta key to _meta
sentry.io cannot handle "" as meta key, only "_meta"


Discussion:

Resolving patch:
diff --git a/sentry_sdk/utils.py b/sentry_sdk/utils.py
--- a/sentry_sdk/utils.py
+++ b/sentry_sdk/utils.py
@@ -552,7 +552,7 @@ def inner(obj):
 
     obj, meta = inner(obj)
     if meta is not None:
-        obj[""] = meta
+        obj["_meta"] = meta
     return obj
 
 


Test patch:
diff --git a/tests/integrations/django/test_basic.py b/tests/integrations/django/test_basic.py
--- a/tests/integrations/django/test_basic.py
+++ b/tests/integrations/django/test_basic.py
@@ -200,7 +200,10 @@ def test_request_body(sentry_init, client, capture_events):
 
     assert event["message"] == "hi"
     assert event["request"]["data"] == ""
-    assert event[""]["request"]["data"][""] == {"len": 6, "rem": [["!raw", "x", 0, 6]]}
+    assert event["_meta"]["request"]["data"][""] == {
+        "len": 6,
+        "rem": [["!raw", "x", 0, 6]],
+    }
 
     del events[:]
 
diff --git a/tests/integrations/flask/test_flask.py b/tests/integrations/flask/test_flask.py
--- a/tests/integrations/flask/test_flask.py
+++ b/tests/integrations/flask/test_flask.py
@@ -203,7 +203,7 @@ def index():
     assert response.status_code == 200
 
     event, = events
-    assert event[""]["request"]["data"]["foo"]["bar"] == {
+    assert event["_meta"]["request"]["data"]["foo"]["bar"] == {
         "": {"len": 2000, "rem": [["!limit", "x", 509, 512]]}
     }
     assert len(event["request"]["data"]["foo"]["bar"]) == 512
@@ -229,7 +229,7 @@ def index():
     assert response.status_code == 200
 
     event, = events
-    assert event[""]["request"]["data"]["foo"] == {
+    assert event["_meta"]["request"]["data"]["foo"] == {
         "": {"len": 2000, "rem": [["!limit", "x", 509, 512]]}
     }
     assert len(event["request"]["data"]["foo"]) == 512
@@ -259,7 +259,7 @@ def index():
     assert response.status_code == 200
 
     event, = events
-    assert event[""]["request"]["data"] == {
+    assert event["_meta"]["request"]["data"] == {
         "": {"len": 2000, "rem": [["!config", "x", 0, 2000]]}
     }
     assert not event["request"]["data"]
@@ -285,12 +285,12 @@ def index():
     assert response.status_code == 200
 
     event, = events
-    assert event[""]["request"]["data"]["foo"] == {
+    assert event["_meta"]["request"]["data"]["foo"] == {
         "": {"len": 2000, "rem": [["!limit", "x", 509, 512]]}
     }
     assert len(event["request"]["data"]["foo"]) == 512
 
-    assert event[""]["request"]["data"]["file"] == {
+    assert event["_meta"]["request"]["data"]["file"] == {
         "": {"len": 0, "rem": [["!raw", "x", 0, 0]]}
     }
     assert not event["request"]["data"]["file"]
diff --git a/tests/test_event.py b/tests/test_event.py
--- a/tests/test_event.py
+++ b/tests/test_event.py
@@ -6,7 +6,7 @@ def test_flatten_metadata():
     assert flatten_metadata({"foo": ["bar"]}) == {"foo": [u"bar"]}
     assert flatten_metadata({"foo": [AnnotatedValue("bar", u"meta")]}) == {
         "foo": [u"bar"],
-        "": {"foo": {"0": {"": u"meta"}}},
+        "_meta": {"foo": {"0": {"": u"meta"}}},
     }
Repository: getsentry/sentry-python

Issue:
Log more extra data for Celery
The old integration in celery used to log arguments to the task and more. Add that to our celery integration


Discussion:

Resolving patch:
diff --git a/sentry_sdk/integrations/celery.py b/sentry_sdk/integrations/celery.py
--- a/sentry_sdk/integrations/celery.py
+++ b/sentry_sdk/integrations/celery.py
@@ -35,28 +35,48 @@ def _process_failure_signal(sender, task_id, einfo, **kw):
     if integration is None:
         return
 
-    if hasattr(sender, "throws") and isinstance(einfo.exception, sender.throws):
-        return
-
-    if isinstance(einfo.exception, SoftTimeLimitExceeded):
-        # TODO: Move this into event processor
-        with hub.push_scope() as scope:
-            scope.fingerprint = [
-                "celery",
-                "SoftTimeLimitExceeded",
-                getattr(sender, "name", sender),
-            ]
-            _capture_event(hub, exc_info)
-    else:
-        _capture_event(hub, exc_info)
+    _capture_event(hub, exc_info)
 
 
-def _handle_task_prerun(sender, task, **kw):
+def _handle_task_prerun(sender, task, args, kwargs, **_):
     hub = Hub.current
     if hub.get_integration(CeleryIntegration) is not None:
         scope = hub.push_scope().__enter__()
+        scope.add_event_processor(_make_event_processor(args, kwargs, task))
+
+
+def _make_event_processor(args, kwargs, task):
+    def event_processor(event, hint):
+        with capture_internal_exceptions():
+            if "transaction" not in event:
+                event["transaction"] = task.name
+
         with capture_internal_exceptions():
-            scope.transaction = task.name
+            extra = event.setdefault("extra", {})
+            extra["celery-job"] = {
+                "task_name": task.name,
+                "args": args,
+                "kwargs": kwargs,
+            }
+
+        if "exc_info" in hint:
+            with capture_internal_exceptions():
+                if issubclass(hint["exc_info"][0], SoftTimeLimitExceeded):
+                    event["fingerprint"] = [
+                        "celery",
+                        "SoftTimeLimitExceeded",
+                        getattr(task, "name", task),
+                    ]
+
+            with capture_internal_exceptions():
+                if hasattr(task, "throws") and isinstance(
+                    hint["exc_info"][1], task.throws
+                ):
+                    return None
+
+        return event
+
+    return event_processor
 
 
 def _handle_task_postrun(sender, task_id, task, **kw):


Test patch:
diff --git a/tests/integrations/celery/test_celery.py b/tests/integrations/celery/test_celery.py
--- a/tests/integrations/celery/test_celery.py
+++ b/tests/integrations/celery/test_celery.py
@@ -27,6 +27,11 @@ def dummy_task(x, y):
     dummy_task.delay(1, 0)
     event, = events
     assert event["transaction"] == "dummy_task"
+    assert event["extra"]["celery-job"] == {
+        "args": [1, 0],
+        "kwargs": {},
+        "task_name": "dummy_task",
+    }
 
     exception, = event["exception"]["values"]
     assert exception["type"] == "ZeroDivisionError"
Repository: getsentry/sentry-python

Issue:
Package not classified as Python 3 compatible 
* `sentry-sdk` is classified as not Python 3 compatible by [pyup](https://pyup.io) when it actually is - e.g. [https://pyup.io/repos/github/pushresume/backend](https://pyup.io/repos/github/pushresume/backend)

![image](https://user-images.githubusercontent.com/19856859/47429544-63446a00-d79f-11e8-8f9b-ac6d2bd3b805.png)

* `setup.py` classifiers should be updated with `Programming Language :: Python :: 3`


Discussion:
You're right. This package is actually missing all classifiers

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -23,4 +23,20 @@
     license="BSD",
     install_requires=["urllib3", "certifi"],
     extras_require={"flask": ["flask>=0.8", "blinker>=1.1"]},
+    classifiers=[
+        'Development Status :: 5 - Production/Stable',
+        'Environment :: Web Environment',
+        'Intended Audience :: Developers',
+        'License :: OSI Approved :: BSD License',
+        'Operating System :: OS Independent',
+        'Programming Language :: Python',
+        'Programming Language :: Python :: 2',
+        'Programming Language :: Python :: 2.7',
+        'Programming Language :: Python :: 3',
+        'Programming Language :: Python :: 3.4',
+        'Programming Language :: Python :: 3.5',
+        'Programming Language :: Python :: 3.6',
+        'Programming Language :: Python :: 3.7',
+        'Topic :: Software Development :: Libraries :: Python Modules',
+    ],
 )


Test patch: