'TypeError: __init__() got an unexpected keyword argument 'providing_args'

I am creating a Django website. I was recently adding permissions/search functionality using the allauth package. When I attempt to run the website through docker I receive the error message:

File "/usr/local/lib/python3.9/site-packages/allauth/account/signals.py", line 5, in user_logged_in = Signal(providing_args=["request", "user"]) TypeError: init() got an unexpected keyword argument 'providing_args'

What is causing this error? I know usually a type error is caused by incorrect models.py files but I can't seem to access this file since it is a part of an external package.

Urls.py

urlpatterns = [
    path('admin/', admin.site.urls),

    path('accounts/', include('allauth.urls')),

    path('accounts/', include('accounts.urls')),
    
    path('', include('climate.urls')),
    
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

if settings.DEBUG:
    import debug_toolbar
    urlpatterns = [
        path('__debug__/', include(debug_toolbar.urls)),
    ] + urlpatterns

Models.py

class Country(models.Model):
    id = models.UUIDField(
        primary_key= True,
        db_index = True,
        default=uuid.uuid4,
        editable= False
    )
    name = models.CharField(max_length=50)
    population = models.IntegerField(default=1)
    emissions = models.FloatField(default=1)
    reason = models.CharField(default="", max_length=100)
    flags = models.ImageField(upload_to='images/', default="")
    page = models.URLField(max_length=300, default="")

    def save(self, *args, **kwargs):
        super(Country, self).save(*args, **kwargs)

    class Meta:
        verbose_name_plural = 'countries'
        indexes = [
            models.Index(fields=['id'], name='id_index')
        ]
        permissions = {
            ("special_status", "Can read all countries")
        }

    def __str__(self):
        return self.name

    def flag(self):
        return u'<img src="%s" />' % (self.flags.url)

    def get_absolute_url(self):
        return reverse('country_detail', args =[str(self.id)])

    flag.short_description = 'Flag'

My settings.py that handles allauth.

AUTH_USER_MODEL = 'accounts.CustomUser'
LOGIN_REDIRECT_URL = 'climate:home'
ACCOUNT_LOGOUT_REDIRECT = 'climate:home'
ACCOUNT_SESSION_REMEMBER = True
ACCOUNT_SIGNUP_PASSWORD_ENTER_TWICE = False
ACCOUNT_USERNAME_REQUIRED = False
ACCOUNT_AUTHENTICATION_METHOD = 'email'
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_UNIQUE_EMAIL = True

Full Traceback:

Traceback (most recent call last):

  File "/usr/local/lib/python3.9/threading.py", line 954, in _bootstrap_inner

    self.run()

  File "/usr/local/lib/python3.9/threading.py", line 892, in run

    self._target(*self._args, **self._kwargs)

  File "/usr/local/lib/python3.9/site-packages/django/utils/autoreload.py", line 64, in wrapper

    fn(*args, **kwargs)

  File "/usr/local/lib/python3.9/site-packages/django/core/management/commands/runserver.py", line 115, in inner_run

    autoreload.raise_last_exception()

  File "/usr/local/lib/python3.9/site-packages/django/utils/autoreload.py", line 87, in raise_last_exception

    raise _exception[1]

  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 381, in execute

    autoreload.check_errors(django.setup)()

  File "/usr/local/lib/python3.9/site-packages/django/utils/autoreload.py", line 64, in wrapper

    fn(*args, **kwargs)

  File "/usr/local/lib/python3.9/site-packages/django/__init__.py", line 24, in setup

    apps.populate(settings.INSTALLED_APPS)

  File "/usr/local/lib/python3.9/site-packages/django/apps/registry.py", line 114, in populate

    app_config.import_models()

  File "/usr/local/lib/python3.9/site-packages/django/apps/config.py", line 300, in import_models

    self.models_module = import_module(models_module_name)

  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module

    return _bootstrap._gcd_import(name[level:], package, level)

  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import

  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load

  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked

  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked

  File "<frozen importlib._bootstrap_external>", line 790, in exec_module

  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed

  File "/usr/local/lib/python3.9/site-packages/allauth/account/models.py", line 12, in <module>

    from . import app_settings, signals

  File "/usr/local/lib/python3.9/site-packages/allauth/account/signals.py", line 5, in <module>

    user_logged_in = Signal(providing_args=["request", "user"])

TypeError: __init__() got an unexpected keyword argument 'providing_args'


Solution 1:[1]

Based on the comments, you're running Django 4.0 with an old version of AllAuth. So you just need to update AllAuth and should be fine.


However, other people who have upgraded AllAuth and are running Django 4.0 but still seeing this error may have custom AllAuth or other signals registered that include the providing_args argument.

In this case, you need to search your project for any signals (such as those often overridden in AllAuth: user_logged_in or email_changed) and remove the providing_args=['request', 'user', 'signup'] or other variation from the Signal parenthesis.

See below for more information, and an example diff showing how you could move each providing_args argument to a commented line.


Django deprecated the ability to use the providing_args argument to django.dispatch.Signal in Django 3.1. See bullet in the Misc section of the 3.1 release notes.

It was removed because this argument doesn't do anything other than act as documentation. If that seems strange, it is because it is strange. Arguments should indicate data getting passed. This is probably why it was deprecated.

Django 4.0 went ahead and removed this altogether, making any code that calls Signal() with the providing_args argument now trigger the TypeError you encountered:

TypeError: Signal.__init__() got an unexpected keyword argument 'providing_args'

AllAuth removed the use of this argument in September of 2020. (See original report on this issue here and the referenced diff)

The person asking the question in this thread was running AllAuth 0.42.0 which does not include this change and is thus incompatible with Django 4.0.

As of today, the last version of Django AllAuth 0.42.0 is compatible with is Django 3.2.9.

Solution 2:[2]

I solved the same problem by replacing

check_request_enabled = Signal(providing_args=["request"])

to

check_request_enabled = Signal("request")

and now its working perfectly.

Solution 3:[3]

i don't know why this happening but (it works on my machine) i solved the same problem by replacing

user_logged_in = Signal(providing_args=["request", "user"])

with

user_logged_in = Signal()

in /usr/local/lib/python3.9/site-packages/allauth/account/signals.py

Solution 4:[4]

This is for anyone who faces the same issue on Django 4.0 and is not using AllAuth.

I ran into a similar issue. However, I was not using AllAuth. The problem is that Django 4.0 does not have any providing_args parameter, so the signal is declared this way.

from django.dispatch import Signal

model_delete_signal = Signal()

Now, you can send any arguments when sending the signal, which will be received in kwargs in the receiver.

For example, I sent the following instance argument while sending the signal in my custom delete function

model_delete_signal.send(sender='session_delete', instance=self)

and received it this way inside the receiver

@receiver(session_delete)
def delete_session(sender, **kwargs):
    instance = kwargs['instance']

Note that, the solution is the same for any Django versions that don't have providing_args parameter in Singal()

Solution 5:[5]

There are better explanations to the question but this is what worked for me...

According to Django

The purely documentational providing_args argument for Signal is deprecated. If you rely on this argument as documentation, you can move the text to a code comment or docstring.

Just comment out the following code from signals.py file in your local project storage:

user_logged_in = Signal(providing_args=["request", "user"])

# Typically followed by `user_logged_in` (unless, e-mail verification kicks in)
user_signed_up = Signal(providing_args=["request", "user"])

password_set = Signal(providing_args=["request", "user"])
password_changed = Signal(providing_args=["request", "user"])
password_reset = Signal(providing_args=["request", "user"])

email_confirmed = Signal(providing_args=["request", "email_address"])
email_confirmation_sent = Signal(
    providing_args=["request", "confirmation", "signup"])

email_changed = Signal(
    providing_args=[
        "request", "user",
        "from_email_address", "to_email_address"])
email_added = Signal(providing_args=["request", "user", "email_address"])
email_removed = Signal(providing_args=["request", "user", "email_address"])

You can find this in /usr/local/lib/python3.10/site-packages/allauth/account/signals.py

Solution 6:[6]

From the django documentation for django 3.1:

The purely documentational providing_args argument for Signal is deprecated. If you rely on this argument as documentation, you can move the text to a code comment or docstring.

Solution 7:[7]

You can use Signal without argument in new version of Django 4. like this

from django.dispatch import Signal, receiver
notification=Signal()
@receiver(notification)
def show_notification(sender, **kwargs):
    print("sender,", sender)
    print("Kwargs", kwargs)
    print("Notification")        

and after where you use this Signal write like this

notification.send(sender=None, request=request, user=['Sakib', 'Malik'])

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Wtower
Solution 3 Oussama Tachi
Solution 4 Muhammad Zubair
Solution 5
Solution 6 Pierre.Sassoulas
Solution 7 Peter Csala