Separating remote vs local settings.py parameters - - “EMAIL”?

[drone4four]

If you take a look at this gist provided by a Udemy instructor and at this specific location, here he wisely recommends separating important local development configuration parameters, such as SECRET _KEY. Of course everyone knows how stupid and foolish it would be to share the SECRET_KEY publicly on GitHub and then to use it in your production environment.

So here is the list of parameters to place in the separate remote settings.py as it appears in that gist linked to above:

• SECRET_KEY

• ALLOWED_HOSTS

• DATABASES

• DEBUG

• EMAIL_*

If you look at the last one, it says: “EMAIL_*”. What do you people think the “_*” suffix? Is this standard for settings.py configurations? Or would you people think this is just a glaring typo on the side of the instructor?

[Ahmed Ishtiaque]

The character "*" represents "wildcard". Here is the real reason why the instructor puts it that way: https://docs.djangoproject.com/en/2.1/ref/settings/#email-backend

There are a lot of variables that contain the 'EMAIL_' prefix, which is why the instructor wrote it that way.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fa499e85-b7cd-43a1-b21a-e8d6c665e498%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[drone4four]

So the remote server production email contact information could be different from the developer’s testcase email contact info?

I’ve taken a closer look at the “email-backend” section of the Django docs that you’ve linked to, Ahmed. I see Django supports email settings.  I don’t really understand what these EMAIL parameters would be used for. For example, EMAIL_BACKEND says:

Default: 'django.core.mail.backends.smtp.EmailBackend'
The backend to use for sending emails. For the list of available backends see Sending email.

I followed these two links and it is still not clear to me: Are these email settings only used if I implement SMTP or other email services?

Would it be OK for me to just exclude altogether “EMAIL_*” until I reach a point when there is a need for an SMTP server (which will probably be never for the project I am working on)?

[Ahmed Ishtiaque]

If you don't need to send e-mail to your users then it's best not to specify any of the EMAIL_* settings. You can change the backend you use to send email with using EMAIL_BACKEND variable. This can be useful when you're tring to test your email format and such while developing your app. The django.core.mail.smtp.EmailBackend, as far as I remember, sends emails to your development server terminal so you can take a look at a text rendering of the email you're trying to test. If you want to hook up an external e-mail service for  your users in deployment, you can use email services like SendGrid, Mailchimp, etc. and these services use SMTP servers to send e-mails. Django lets you configure these as well. This tutorial helped me understand how sending e-mail to users in deployment works: https://simpleisbetterthancomplex.com/tutorial/2016/06/13/how-to-send-email.html

Since it makes use of an external mail service, you might find it helpful to understand the EMAIL_* variables.

But again, if you don't need to programmatically send e-mails to your users, don't bother specifying these settings. 

[Phillip Moracha]

If you take a look at this gist provided by a Udemy instructor and at this specific location, here he wisely recommends separating important local development configuration parameters, such as SECRET _KEY. Of course everyone knows how stupid and foolish it would be to share the SECRET_KEY publicly on GitHub and then to use it in your production environment.