internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: cupy/cupy

Issue:
`pip install cupy-wheel` - "not a valid wheel filename"
### Description

When I try to `pip install cupy-wheel` I get the error `cupy_wheel<...>.whl is not a valid wheel filename`.

### To Reproduce

```bash
pip install cupy-wheel
```
OS: Windows 10
Python: 3.8.9
pip: 23.1.2
CUDA: CUDA 11.7

### Installation

None

### Environment

Unable to install using `cupy-wheel`. Can install using `pip install cupy-cuda11x`.

### Additional Information

_No response_


Discussion:
Hi @yonting, thanks for reporting - confirmed on my end. This is due to that pip 23.1 has changed it's behavior.

https://pip.pypa.io/en/stable/news/#v23-1

> Remove setup.py install fallback when building a wheel failed for projects without pyproject.toml.

I'll try fixing the issue.

Resolving patch:
diff --git a/install/universal_pkg/setup.py b/install/universal_pkg/setup.py
--- a/install/universal_pkg/setup.py
+++ b/install/universal_pkg/setup.py
@@ -2,12 +2,13 @@
 import pkg_resources
 import os
 import sys
-from typing import Dict, List, Optional
+from typing import List, Optional
 
 from setuptools import setup
 
 
 VERSION = '13.0.0a1'
+META_VERSION = VERSION
 
 # List of packages supported by this version of CuPy.
 PACKAGES = [
@@ -259,20 +260,6 @@ def infer_best_package() -> str:
         'Unable to detect NVIDIA CUDA or AMD ROCm installation.')
 
 
-def _get_cmdclass(tag: str) -> Dict[str, type]:
-    try:
-        import wheel.bdist_wheel
-    except ModuleNotFoundError:
-        return {}
-
-    class bdist_wheel_with_tag(wheel.bdist_wheel.bdist_wheel):  # type: ignore[misc] # NOQA
-        def initialize_options(self) -> None:
-            super().initialize_options()
-            self.build_number = f'0_{tag}'
-
-    return {"bdist_wheel": bdist_wheel_with_tag}
-
-
 #
 # Entrypoint
 #
@@ -283,17 +270,14 @@ def main() -> None:
         requires = f'{package}=={VERSION}'
         _log(f'Installing package: {requires}')
         install_requires = [requires]
-        tag = package
     else:
         _log('Building cupy-wheel package for release.')
         install_requires = []
-        tag = '0'
 
     setup(
         name='cupy-wheel',
-        version=f'{VERSION}',
+        version=META_VERSION,
         install_requires=install_requires,
-        cmdclass=_get_cmdclass(tag),
     )
 
 


Test patch:
Repository: pytest-dev/pytest-django

Issue:
Travis: tests should include all Django versions on Python 2 and 3
It looks like the matrix generation from generate-configurations does not make sure that every Django version is tested on Python 2 and 3: https://travis-ci.org/pytest-dev/pytest-django/builds/50237861

It would be better to see that Django 1.5 also fails on Python 2.7.



Discussion:

Resolving patch:
diff --git a/generate_configurations.py b/generate_configurations.py
--- a/generate_configurations.py
+++ b/generate_configurations.py
@@ -24,6 +24,7 @@ def is_pypy(self):
 
 # Python to run tox.
 RUN_PYTHON = '3.4'
+PYTHON_MAIN_VERSIONS = ['python2.7', 'python3.4']
 PYTHON_VERSIONS = ['python2.6', 'python2.7', 'python3.2', 'python3.3',
                    'python3.4', 'pypy', 'pypy3']
 PYTEST_VERSIONS = ['2.6.4']
@@ -160,6 +161,10 @@ def find_and_add(variations, env_getter):
                     result.add(env)
                     break
 
+    # Add all Django versions for each main python version (2.x and 3.x).
+    find_and_add(itertools.product(PYTHON_MAIN_VERSIONS, DJANGO_VERSIONS),
+                 lambda env: (env.python_version, env.django_version))
+
     find_and_add(PYTHON_VERSIONS, lambda env: env.python_version)
     find_and_add(PYTEST_VERSIONS, lambda env: env.pytest_version)
     find_and_add(DJANGO_VERSIONS, lambda env: env.django_version)


Test patch:
Repository: pytest-dev/pytest-django

Issue:
Support settings DJANGO_SETTINGS_MODULE in pytest_configure
See comment in #119, this should be possible:

``` python
import os

def pytest_configure():
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')
```



Discussion:
> _configuring DJANGO_SETTINGS_MODULE in pytest_configure is not really supported/tested at the moment, but should be easy to support properly_.

How easy is it? I need this to switch to Django 1.7 + pytest-django 2.7, otherwise I'm forced to call `setup()` manually.

Actually, I think this works and the issue should be closed. Could you give it a try if you haven't?

There doesn't seem to be a test for this case, so that should probably be added to make sure it doesn't accidentally break.


Resolving patch:
diff --git a/pytest_django/lazy_django.py b/pytest_django/lazy_django.py
--- a/pytest_django/lazy_django.py
+++ b/pytest_django/lazy_django.py
@@ -22,8 +22,6 @@ def django_settings_is_configured():
 
     # If DJANGO_SETTINGS_MODULE is defined at this point, Django is assumed to
     # always be loaded.
-    from django.conf import settings
-    assert settings.configured is True
     return True
 
 


Test patch:
diff --git a/tests/test_django_settings_module.py b/tests/test_django_settings_module.py
--- a/tests/test_django_settings_module.py
+++ b/tests/test_django_settings_module.py
@@ -96,6 +96,25 @@ def test_ds_after_user_conftest(testdir, monkeypatch):
     result.stdout.fnmatch_lines(['*1 passed*'])
 
 
+def test_ds_in_pytest_configure(testdir, monkeypatch):
+    monkeypatch.delenv('DJANGO_SETTINGS_MODULE')
+    pkg = testdir.mkpydir('tpkg')
+    settings = pkg.join('settings_ds.py')
+    settings.write(BARE_SETTINGS)
+    testdir.makeconftest("""
+        import os
+
+        from django.conf import settings
+
+        def pytest_configure():
+            if not settings.configured:
+                os.environ.setdefault('DJANGO_SETTINGS_MODULE',
+                                      'tpkg.settings_ds')
+    """)
+    r = testdir.runpytest()
+    assert r.ret == 0
+
+
 def test_django_settings_configure(testdir, monkeypatch):
     """
     Make sure Django can be configured without setting
Repository: pytest-dev/pytest-django

Issue:
Use django.test.utils.{setup_databases,teardown_databases}
This makes it possible for us not not rely on Django's DiscoverRunner.

https://github.com/django/django/commit/e76981b43325da60b8a7475661df6cbfa7fda37e

This also fixes a deprecation warning in current Django master.



Discussion:

Resolving patch:
diff --git a/pytest_django/compat.py b/pytest_django/compat.py
new file mode 100644
--- /dev/null
+++ b/pytest_django/compat.py
@@ -0,0 +1,11 @@
+try:
+    # Django 1.11
+    from django.test.utils import setup_databases, teardown_databases  # noqa
+except ImportError:
+    # In Django prior to 1.11, teardown_databases is only available as a method on DiscoverRunner
+    from django.test.runner import setup_databases, DiscoverRunner as _DiscoverRunner  # noqa
+
+    def teardown_databases(db_cfg, verbosity):
+        (_DiscoverRunner(verbosity=verbosity,
+                         interactive=False)
+         .teardown_databases(db_cfg))
diff --git a/pytest_django/fixtures.py b/pytest_django/fixtures.py
--- a/pytest_django/fixtures.py
+++ b/pytest_django/fixtures.py
@@ -72,7 +72,7 @@ def django_db_setup(
     django_db_modify_db_settings,
 ):
     """Top level fixture to ensure test databases are available"""
-    from django.test.runner import setup_databases, DiscoverRunner
+    from .compat import setup_databases, teardown_databases
 
     setup_databases_args = {}
 
@@ -98,9 +98,10 @@ def django_db_setup(
 
     def teardown_database():
         with django_db_blocker:
-            (DiscoverRunner(verbosity=pytest.config.option.verbose,
-                            interactive=False)
-             .teardown_databases(db_cfg))
+            teardown_databases(
+                db_cfg,
+                verbosity=pytest.config.option.verbose,
+            )
 
     if not django_db_keepdb:
         request.addfinalizer(teardown_database)


Test patch:
Repository: pytest-dev/pytest-django

Issue:
Tests are failing for Django master
I'd like to make a release but we should fix this first.

Output from the failing test:
https://travis-ci.org/pytest-dev/pytest-django/jobs/173636497


Discussion:
It seems to be related to the `--nomigrations` hack IIRC.

Not sure if I am missing something, but with `--nomigrations` there happens still a bit too much, which can be seen with `pytest -s`:

```
Using existing test database for alias 'default' ('test_app')...
Operations to perform:
  Synchronize unmigrated apps: admin, auth, …, staticfiles
  Apply all migrations: (none)
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  No migrations to apply.
```

Might be nice to avoid/skip this also, when fixing this for Django master.

Just curious, why do we care for Django-master to pass? Is it just to be able to quickly be able to release a pytest-django when new version of Django comes out? If so, aren't the Django release candidates better approach to not need to maintain and keep releases back just because Django master tests are failing?

Some libraries (i.e. djangorestframework) uses pytest-django and tests regularly against Django master. If we do not support Django master properly, those projects can't either.

Also people contributing to Django itself may use pytest-django to test other projects. It can be useful to try out new Django features in real projects test suites before merging to Django.

Therefore we need to be a bit more generous in our supported versions than typical libraries. We also still support Django 1.7 even though it is not supported by Django itself. Getting the test suite to even run is usually the first step to upgrade to new Django versions.

Sounds fair :)

Anyone looking for a new release and found this issue, help fixing the migration problem would be very appreciated 👐 😃 


Resolving patch:
diff --git a/pytest_django/migrations.py b/pytest_django/migrations.py
--- a/pytest_django/migrations.py
+++ b/pytest_django/migrations.py
@@ -1,8 +1,17 @@
 # code snippet copied from https://gist.github.com/NotSqrt/5f3c76cd15e40ef62d09
+from pytest_django.lazy_django import get_django_version
+
+
 class DisableMigrations(object):
 
+    def __init__(self):
+        self._django_version = get_django_version()
+
     def __contains__(self, item):
         return True
 
     def __getitem__(self, item):
-        return "notmigrations"
+        if self._django_version >= (1, 9):
+            return None
+        else:
+            return 'notmigrations'


Test patch:
Repository: pytest-dev/pytest-django

Issue:
Test re-ordering breaks Pytest's --failed-first and --stepwise options
The test re-ordering introduced in response to #214 seems to execute after pytest's own `--failed-first`, `--new-first`, `--stepwise`, etc. ordering options, breaking them.

We ran across this in mdn/kuma#6531, where even with `--failed-first` pytest was running dozens of known good tests before executing the failed tests.

Removing the `pytest_collection_modifyitems` function or decorating it with `@pytest.hookimpl(tryfirst=True)` seems to resolve this, though I'm not familiar enough with pytest to know if that's an appropriate solution, or if there's something we should be doing on our end instead.


Discussion:
The function in question can be found at https://github.com/pytest-dev/pytest-django/blob/v3.8.0/pytest_django/plugin.py#L418-L439, and was added in commit 5a79fba3705376c3f89f5a9e26b8244937d61768
Thanks for the report.
Can you try it with pytest master?  IIRC I've fixed something there in this regard.
Thank you for the quick response!

I see the same issue with `pytest-5.3.5.dev399+gf77d606d4`, which is the current head of `master`

```
pytest --ff -x kuma/users/tests/test_views.py                                                                                                    
=== test session starts ===
platform linux -- Python 3.8.0, pytest-5.3.5.dev399+gf77d606d4, py-1.8.1, pluggy-0.13.1
django: settings: kuma.settings.testing (from ini)
rootdir: /app, inifile: pytest.ini
plugins: base-url-1.4.1, celery-4.4.0, django-3.8.0, metadata-1.8.0, requests-mock-1.7.0, cov-2.8.1, rerunfailures-8.0
collected 72 items                                                                                                                                                                                         
run-last-failure: rerun previous 1 failure first

kuma/users/tests/test_views.py ............................F
```
Ok.  Using `@pytest.hookimpl(tryfirst=True)` then seems to be sensible.
Would you like to create a PR for this?

(I was thinking of https://github.com/pytest-dev/pytest/commit/f75f7c192586fd856dad10673cd6d1f8cce03f75, which fixed it for pytest's own tests)

Resolving patch:
diff --git a/pytest_django/plugin.py b/pytest_django/plugin.py
--- a/pytest_django/plugin.py
+++ b/pytest_django/plugin.py
@@ -415,6 +415,7 @@ def pytest_runtest_setup(item):
             _disable_class_methods(item.cls)
 
 
+@pytest.hookimpl(tryfirst=True)
 def pytest_collection_modifyitems(items):
     def get_order_number(test):
         marker_db = test.get_closest_marker('django_db')


Test patch:
Repository: pytest-dev/pytest-django

Issue:
admin_client is not checking for login success
`client.login` inside `admin_client` can return `False` in the case when there's an existing admin user with a password set to something other than `'password'`. Perhaps, `admin_client` should use `force_login` instead?


Discussion:
Seems sensible
Can you provide a failing test and fix in a PR?
Sure, I'll do that in the next couple of days.

Resolving patch:
diff --git a/pytest_django/fixtures.py b/pytest_django/fixtures.py
--- a/pytest_django/fixtures.py
+++ b/pytest_django/fixtures.py
@@ -304,7 +304,7 @@ def admin_client(db, admin_user):
     from django.test.client import Client
 
     client = Client()
-    client.login(username=admin_user.username, password="password")
+    client.force_login(admin_user)
     return client
 
 


Test patch:
diff --git a/tests/test_fixtures.py b/tests/test_fixtures.py
--- a/tests/test_fixtures.py
+++ b/tests/test_fixtures.py
@@ -49,6 +49,17 @@ def test_admin_client_no_db_marker(admin_client):
     assert force_str(resp.content) == "You are an admin"
 
 
+# For test below.
+@pytest.fixture
+def existing_admin_user(django_user_model):
+    return django_user_model._default_manager.create_superuser('admin', None, None)
+
+
+def test_admin_client_existing_user(db, existing_admin_user, admin_user, admin_client):
+    resp = admin_client.get("/admin-required/")
+    assert force_str(resp.content) == "You are an admin"
+
+
 @pytest.mark.django_db
 def test_admin_user(admin_user, django_user_model):
     assert isinstance(admin_user, django_user_model)
Repository: pytest-dev/pytest-django

Issue:
Handle transaction.atomic(durable=True)
This argument will be introduced in Django 3.2: https://docs.djangoproject.com/en/3.2/topics/db/transactions/#controlling-transactions-explicitly

It's used to make sure that atomic blocks aren't nested and naturally this fails when running the test suite. The django `TestCase`-class handles this by setting `transaction.Atomic._ensure_durability = False` in `setUpClass` and setting it back to `True` on `tearDownClass`.

I'm not that familiar with the codebase but I wonder if it would make sense to adjust the non-transactional block in `_django_db_fixture_helper` with something like:
```python
transaction.Atomic._ensure_durability = False
def reset_durability():
    transaction.Atomic._ensure_durability = True
request.addfinalizer(reset_durability)
```


Discussion:

Resolving patch:
diff --git a/pytest_django/fixtures.py b/pytest_django/fixtures.py
--- a/pytest_django/fixtures.py
+++ b/pytest_django/fixtures.py
@@ -147,6 +147,12 @@ class ResetSequenceTestCase(django_case):
             django_case = ResetSequenceTestCase
     else:
         from django.test import TestCase as django_case
+        from django.db import transaction
+        transaction.Atomic._ensure_durability = False
+
+        def reset_durability():
+            transaction.Atomic._ensure_durability = True
+        request.addfinalizer(reset_durability)
 
     test_case = django_case(methodName="__init__")
     test_case._pre_setup()


Test patch:
diff --git a/tests/test_database.py b/tests/test_database.py
--- a/tests/test_database.py
+++ b/tests/test_database.py
@@ -1,7 +1,8 @@
 import pytest
-from django.db import connection
+from django.db import connection, transaction
 from django.test.testcases import connections_support_transactions
 
+from pytest_django.lazy_django import get_django_version
 from pytest_django_test.app.models import Item
 
 
@@ -138,6 +139,12 @@ def test_fin(self, fin):
         # Check finalizer has db access (teardown will fail if not)
         pass
 
+    @pytest.mark.skipif(get_django_version() < (3, 2), reason="Django >= 3.2 required")
+    def test_durable_transactions(self, all_dbs):
+        with transaction.atomic(durable=True):
+            item = Item.objects.create(name="foo")
+        assert Item.objects.get() == item
+
 
 class TestDatabaseFixturesAllOrder:
     @pytest.fixture
Repository: pytest-dev/pytest-django

Issue:
4.5.1: reset_sequences=True fails on MariaDB/MySQL
Firstly, thanks for maintaining such a powerful and useful testing library for Django.

On to the bug:

- OS: Windows 10
- Python: 3.9.1
- pytest-6.2.5
- py-1.11.0
- pluggy-1.0.0
- Django: 3.2.10

Example:

    @pytest.mark.django_db(reset_sequences=True)
    def test_reset_sequences():
        assert True

Output:

    ERROR my_test.py::test_reset_sequences - AssertionError: reset_sequences cannot be used on TestCase instances


Discussion:
It's missing `transaction=True`. Needs a better error message.

Did it work on pytest-django 4.4.0? If yes, then I'll make it work again.
Thanks for the fast response! Yes it works on 4.5.0

Resolving patch:
diff --git a/pytest_django/fixtures.py b/pytest_django/fixtures.py
--- a/pytest_django/fixtures.py
+++ b/pytest_django/fixtures.py
@@ -167,7 +167,7 @@ def _django_db_helper(
             serialized_rollback,
         ) = False, False, None, False
 
-    transactional = transactional or (
+    transactional = transactional or reset_sequences or (
         "transactional_db" in request.fixturenames
         or "live_server" in request.fixturenames
     )


Test patch:
diff --git a/tests/test_database.py b/tests/test_database.py
--- a/tests/test_database.py
+++ b/tests/test_database.py
@@ -287,11 +287,16 @@ def test_reset_sequences_disabled(self, request) -> None:
         marker = request.node.get_closest_marker("django_db")
         assert not marker.kwargs
 
-    @pytest.mark.django_db(transaction=True, reset_sequences=True)
+    @pytest.mark.django_db(reset_sequences=True)
     def test_reset_sequences_enabled(self, request) -> None:
         marker = request.node.get_closest_marker("django_db")
         assert marker.kwargs["reset_sequences"]
 
+    @pytest.mark.django_db(transaction=True, reset_sequences=True)
+    def test_transaction_reset_sequences_enabled(self, request) -> None:
+        marker = request.node.get_closest_marker("django_db")
+        assert marker.kwargs["reset_sequences"]
+
     @pytest.mark.django_db(databases=['default', 'replica', 'second'])
     def test_databases(self, request) -> None:
         marker = request.node.get_closest_marker("django_db")
Repository: pytest-dev/pytest-django

Issue:
assertRaisesMessage expects wrong excepted_exception type
I am trying to use `assertRaisesMessage` to test for `save()` raising an `IntegrityError`. However, the `expected_exception` expected type is `BaseException`.

vscode shows me `Type[Exception]` for `TestCase.assertRaisesMessage`.

Code snippet:

```python
from django.db.utils import IntegrityError
from pytest_django.asserts import assertRaisesMessage

def test_some_functionality():
    with assertRaisesMessage(IntegrityError, constraint_name):
        user.save()
```

mypy error:

> Argument 1 to "assertRaisesMessage" has incompatible type "Type[IntegrityError]"; expected "BaseException"  [arg-type]mypy(error)





Discussion:

Resolving patch:
diff --git a/pytest_django/asserts.py b/pytest_django/asserts.py
--- a/pytest_django/asserts.py
+++ b/pytest_django/asserts.py
@@ -2,7 +2,7 @@
 Dynamically load all Django assertion cases and expose them for importing.
 """
 from functools import wraps
-from typing import Any, Callable, Optional, Sequence, Set, Union
+from typing import Any, Callable, Optional, Sequence, Set, Type, Union
 
 from django.test import (
     LiveServerTestCase, SimpleTestCase, TestCase, TransactionTestCase,
@@ -113,7 +113,7 @@ def assertTemplateNotUsed(
         ...
 
     def assertRaisesMessage(
-        expected_exception: BaseException,
+        expected_exception: Type[Exception],
         expected_message: str,
         *args,
         **kwargs


Test patch:
Repository: pytest-dev/pytest-django

Issue:
RemovedInDjango51Warning: assertQuerysetEqual() is deprecated in favor of assertQuerySetEqual()
**Background**

In Django 4.2, `assertQuerysetEqual()` is deprecated in favor of `assertQuerySetEqual()`, see release notes: https://docs.djangoproject.com/en/4.2/releases/4.2/#id1

**Steps to reproduce**

```
from pytest_django.asserts import assertQuerysetEqual

assertQuerysetEqual(User.objects.all(), [user])
# django.utils.deprecation.RemovedInDjango51Warning: assertQuerysetEqual() is deprecated in favor of assertQuerySetEqual().
```

**Notes**

- I have my test suite to error out on warnings so this is breaking my build.


Discussion:

Resolving patch:
diff --git a/pytest_django/asserts.py b/pytest_django/asserts.py
--- a/pytest_django/asserts.py
+++ b/pytest_django/asserts.py
@@ -188,6 +188,7 @@ def assertXMLNotEqual(
     ) -> None:
         ...
 
+    # Removed in Django 5.1: use assertQuerySetEqual.
     def assertQuerysetEqual(
         qs,
         values,
@@ -197,6 +198,15 @@ def assertQuerysetEqual(
     ) -> None:
         ...
 
+    def assertQuerySetEqual(
+        qs,
+        values,
+        transform=...,
+        ordered: bool = ...,
+        msg: Optional[str] = ...,
+    ) -> None:
+        ...
+
     def assertNumQueries(
         num: int,
         func=...,


Test patch:
Repository: dj-stripe/dj-stripe

Issue:
Remove subscriber__email from search_fields
> DJSTRIPE_SUBSCRIBER_MODEL must have an email field. If your existing model has no email field, add an email property that defines an email address to use.

Since the `DJSTRIPE_SUBSCRIBER_MODEL` could have email as a property we probably shouldn't be assuming `subscriber__email` in admin `search_fields`.



Discussion:
Good point. If you want to make a quick PR, I'll merge it.


Resolving patch:
diff --git a/djstripe/admin.py b/djstripe/admin.py
--- a/djstripe/admin.py
+++ b/djstripe/admin.py
@@ -93,7 +93,6 @@ def send_charge_receipt(modeladmin, request, queryset):
     search_fields=[
         "stripe_id",
         "customer__stripe_id",
-        "customer__subscriber__email",
         "card_last_4",
         "invoice__stripe_id"
     ],
@@ -147,7 +146,6 @@ def send_charge_receipt(modeladmin, request, queryset):
     search_fields=[
         "stripe_id",
         "customer__stripe_id",
-        "customer__subscriber__email",
         "validated_message"
     ],
 )
@@ -180,8 +178,7 @@ def subscription_status(obj):
         CustomerSubscriptionStatusListFilter
     ],
     search_fields=[
-        "stripe_id",
-        "subscriber__email"
+        "stripe_id"
     ],
     inlines=[CurrentSubscriptionInline]
 )
@@ -221,8 +218,7 @@ def customer_email(obj):
     ],
     search_fields=[
         "stripe_id",
-        "customer__stripe_id",
-        "customer__subscriber__email"
+        "customer__stripe_id"
     ],
     list_filter=[
         InvoiceCustomerHasCardListFilter,


Test patch: