django - settings.py seems to load multiple times? - django

EDIT I miscounted - it is printed out twice, not four times.
I put this in my settings.py
print 'ola!'
and on startup "ola" is printed out twice! This seems like something is wrong with my pycharm django project ... any ideas why this would happen? It isn't in a loop or anything (that i'm aware of, anyway)
cheers!
YAY The user known only as "rohit", as per the comments, has determined that a solution can be found here: https://stackoverflow.com/a/2110584/1061426 ~ see the comment about disabling reloading.
CAUTION I don't have my Django code up and about now, so I don't know what the noload will do. Good luck, soldiers.

If you print out the thread ID within settings.py, you will see that settings.py is actually being loaded on two different threads.
See this stackoverflow response and this article for more info.

Actually what Django does is putting a wrapper around settings. It is basically an object (settings object if you want so) which give you access to some direct setters like settings.WHATEVER, so it appears like you access the global variables in settings.py direclty.
I really don't remember though, why the import happens twice. I looked into it once when I worked on django-dynamic-settings which uses a very similar approach as Django itself.
Anyway, if you are interested in the "magic" you can follow the flow starting from the execute_from_command_line call in manage.py.

Django does some strange things with settings.py, and it will execute more than once. I'm used to seeing it imported twice, not sure why in PyCharm you're getting four times. You have to be careful with statements with side-effects in settings.py.

A closely-related question has been asked at least twice since. I can add that a Django core developer rejected the idea that this is any sort of Django bug; it's normal behavior.
Also see this from Graham Dumpleton.

Related

How can I fix the internal error in Django?

I don't have a lot of experience in Django and I am a fairly green developer. When I run the localhost I keep getting a Internal Error. I have tried most of the solutions to similar problems here and none of them works. Can anyone help me? The code is not mine so I don't want to alter it as such either.
Here is a picture of the errors I keep getting:
The only thing you can do without altering the code is to enter the value "shop_all_art" in the HomePage table in the database.
Do not share code via images. You should also share the related code.
Your stacktrace clearly says, that Python is not able to access first element of HomePage.objects.filter(value='shop_all_art') in file bidgala/bidgala/pages/views.py. all_art_img is most probably empty.
Looks like all_art_img is empty.
you should check if a Query has any elements before with a method such as
if all_art_img.exists():
all_art_img[0]

Questions about Heroku and Django settings

I have tried many, many times to get my apps running on Heroku without success. The fact that they run locally seems to be totally irrelevant. Clearly I don’t understand how this works.
So … here are a couple of questions, which I've decided to group to gether in a single question on SO:
1. Why does Heroku have so many different places that influence the settings (Procfile, wsgi.py, config vars, and settings.py)?
2. How do they relate to one another?
3. Which has precedence?
4. Do they all have to be exactly the same?
5. What am I supposed to do with / how am I supposed to configure the database settings given in the Heroku Django template?
# Parse database configuration from $DATABASE_URL
DATABASES['default'] = dj_database_url.config()
# this line blank in original. I put text here to make it format correctly
# Enable Connection Pooling (if desired)
DATABASES['default']['ENGINE'] = 'django_postgrespool'
a) Doesn’t DATABASE [‘ENGINE’], coming after DATABASE [default] overwrite DATABASE [default]?
b) Why aren’t these two in the same format as the default Django settings, which is a simple dictionary, instead of all these extra and confusing brackets?
c) Are they supposed to be treated as two different settings, so that you have to use database routers if you want both?
d) Why does the devcenter article say to import postgrespool but the template says nothing about that?
e) Why is ‘default’ optional with dj_database_url but mandatory with Django?
f) When I tried commenting out line 82, I got an error about resetting queries, why?
g) I have the postgres string from my config vars as the argument to dj_database_url, but I get a NAME ERROR, database undefined. Why?
You're making this much much much more difficult than it actually is. All dj_database_url does is use an environment variable to create a dictionary suitable for use in the DATABASES setting. It doesn't do anything else.
The devcenter article you link to mentions processpool as a way of increasing concurrency. It doesn't say or even hint that you need it when you're starting out. There is no reason for you to even be reading that article at this point.
The only article you need to read is the Getting started with Django one, which tells you exactly what to do.

Is there an easy way to tell which URLs are unused?

I have a Django project which is entering its fourth year of development. Over those four years, a number of URLs (and therefore view functions) have become obsolete. Instead of deleting them as I go, I've left them in a "just in case" attitude. Now I'm looking to clean out the unused URLs and unused view functions.
Is there any easy way to do this, or is it just a matter of grunting through all the code to figure it out? I'm nervous about deleting something and not realizing it's important until a few weeks/months later.
The idea is to iterate over urlpatterns and check that the status_code is 200:
class BasicTestCase(TestCase):
def test_url_availability(self):
for url in urls.urlpatterns:
self.assertEqual(self.client.get(reverse('%s' % url.name)).status_code,
200)
I understand that it might not work in all cases, since there could be urls with "dynamic" nature with dynamic url parts, but, it should give you the basic idea. Note that reverse() also accepts arguments in case you need to pass arguments to the underlying view.
Also see: Finding unused Django code to remove.
Hope that helps.
You are looking for coverage, which is basically "how much of the code written is actually being used".
Coverage analysis is usually done with tests - to find how what percentage of your code is covered by tests - but there is nothing stopping you to do the same to find out what views are orphaned.
Rather than repeat the process, #sk1p already answered it at How to get coverage data from a django app when running in gunicorn.

Django doesn't read from database – no error

I just set up the environment for an existing Django project, on a new Mac. I know for certain there is nothing wrong with the code itself (just cloned the repo), but for some reason, Django can't seem to retrieve data from the database.
I know the correct tables and data is in the db.
I know the codebase is as it should be.
I can make queries using the Django shell.
Django doesn't throw any errors despite the data missing on the web page.
I realize that it's hard to debug this without further information, but I would really appreciate a finger pointing me to the right direction. I can't seem to find any useful logs.
EDIT:
I just realized the problem lies elsewhere. Unfortunately I can't delete this post with the bounty still open.
Without seeing any code, I can only suggest some general advice that might help you debug your problem. Please add a link to your repository if you can or some snippets of your database settings, the view which includes the database queries etc...
Debugging the view
The first thing I would recommend is using the python debugger inside the view which queries the database. If you've not used pdb before, it's a life saver which allows you to set breakpoints in your Python script and then interactively execute code inside the interpreter
>>> import pdb
>>> pdb.set_trace()
>>> # look at the results of your queries
If you are using the Django ORM, the QuerySet returned from the query should have all the data you expect.
If it doesn't then you need to look into your database configuration in settings.py.
If it does, then you must might not be returning that object to the template? Unlikely as you said the code was the same, but double check the objects you pass with your HttpResponse object.
Debugging the database settings
If you can query the database using the project settings inside settings.py from the django shell it sounds unlikley that there is a problem with this - but like everything double check.
You said that you've set up a new project on a mac. What is on a different operating system before? Maybe there is a problem with the paths now - to make your project platform independent remember to use the os.path.join() method when working with file paths.
And what about the username and password details....
Debugging the template
Maybe your template is referencing the wrong object variable name or object attribute.You mentioned that
Django doesn't throw any errors despite the data missing on the web
page.
This doesn't really tell us much - to quote the Django docs -
If you use a variable that doesn’t exist, the template system will
insert the value of the TEMPLATE_STRING_IF_INVALID setting, which is
set to '' (the empty string) by default.
So to check all the variables available to your template, you could use the debug template tag
{{ debug }}
Probably even better though is to use the django-debugging-toolbar - this will also let you examine the SQL queries your view is making.
Missing Modules
I would expect this to raise an exception if this were the problem, but have you checked that you have the psycopg module on your new machine?

Are Django template tags cached?

I have gone through the (painful) process of writing a custom template tag for use in Django. It is registered as an inclusion_tag so that it renders a template. However, this tag breaks as soon as I try to change something.
I've tried changing the number of parameters and correspondingly changing the parameters when it's called. It's clear the new tag code isn't being loaded, because an error is thrown stating that there is a mismatch in the number of parameters, and it's evident that it's attempting to call the old function.
The same problem occurs if I try to change the name of the template being rendered and correspondingly change the name of the template on disk. It continues to try to call the old template. I've tried clearing old .pyc files with no luck.
Overall, the system is acting as though it's caching the template tags, likely due to the register command. I have dug through endless threads trying to find out if this is so, but all could find it James Bennett stating here that register doesn't do anything. Please help!
I have gone through the (painful) process of writing a custom template tag for use in Django
I agree that the process for writing the template tag in django is more elaborate than it needs to be.
But let me point you towards some of the third party apps, that when installed, a template tag is just another python function (or class).
http://github.com/alex/django-templatetag-sugar
http://github.com/codysoyland/django-template-repl
Firstly, I can't imagine what's complicated about inclusion tags. Writing a completely custom tag from scratch, yes: that's complicated. But inclusion tags are simply three lines of code and a template - what's complicated about that?
Secondly, all Python code in your Django project is loaded once by the server [*], and remains until it is restarted. The dev server usually detects changes and restarts itself to reload the code, but this doesn't always work. You should get into the habit of checking the console to see that it does restart, and doing it manually if necessary. Note that this has nothing whatsoever to do with caching.
[*] strictly speaking, once per process, but the dev server is single-process anyway.
In case anybody else encounters this: the exact caching mechanism is unclear, but restarting the django dev server fixes the problem.