#django

avidal: cool.

interesting: http://dpaste.com/1579329/

create a User model in an 'auth' package that subclasses AbstractBaseUser, and the actual User model becomes a django.contrib.auth.models.User

with all of the attributes that hang off of it

change the package name to something else, eg authz, and that's no longer the case

same with changing the name from User to Whatever, or not subclassing AbstractBaseUser

Well, kind of. Most times you don't want to subclass abstractBaseUser. Most people want AbstractUser, I'm convinced.

Also, gotta make sure the user_model setting is set.

Right, but that's all besides the point

The point here is that creating a model called User that subclasses AbstractBaseUser, within an auth package, replaces the "User" class with "django.contrib.auth.models.User"

and i have no idea why

avidal: Because of how app names work, you can 't have two with the same name. So don't make an app called 'auth'.

I don't even have django.contrib.auth in INSTALLED_APPS, nor is this 'project.auth' package in there

can anyone tell me how to access the view name from view_func in process_view (middleware)?

avidal: What Django version?

1.6.1

avidal: The bug that you're reporting re the User model sounds accurate to me; I think you'll find the behavior in 1.7 (master) more sane.

The app-loading infrastructure has been mostly rewritten, and is stricter about installed vs not-installed apps.

carljm: Is the recommendation to use a different model name or a different package name?

avidal: A different package name. I often use e.g. "users" or "accounts".

(I had a feeling it was related the app loader, although it's very curious behavior anyway)

Basically in Django pre-1.7 the app cache stores info about any app whose models are ever imported, regardless of whether they are installed or not.

So you can have clashes with a contrib app label even if it is not in INSTALLED_APPS.

Ah, I see

If anything imports those models; and some things in Django internally are not careful about what they import (for instance, the test client causes an import of stuff from contrib.auth, to support its login/logout methods). Though a lot of that has been cleaned up in master, too.

It's just curious, because the very act of constructing the class and then importing it in ipython, causes it to be replaced

avidal: right, it's very bad behavior which was introduced for bad reasons: you can find the explanation in ModelBase.__new__

Well I suppose it's not just importing in ipython, because I'm importing it through manage.py shell

(well, not really the explanation of _why_ it was introduced; but you can find the code that does it there)

it was introduced because Django pre-1.4 had a default project setup that tended to cause doubled import paths (where the same Python module could be imported by two different names, e.g. "myproject.myapp" and "myapp"

and so people sometimes would end up with two copies of the same Model class

myproject.myapp.models.MyModel and myapp.models.MyModel

which caused all kinds of exciting problems

:)

so the "fix" that was put in place, back in the mists of time, was to have the Model metaclass (ModelBase) always return a cached model class from the app cache, rather than actually creating a new model class, if it found a match

and that behavior is what explains what you are seeing

Fortunately this bad behavior has also been removed in master / 1.7.

Ah, right. The thing that was tripping me up was it seemed like it was being replaced in locals(), but instead it's actually because the ModelBase metaclass constructor (__new__) which is responsible for actual model class construction, was, instead of creating my new User class, returning the cached auth.User class which was already imported when I imported AbstractBaseUser

precisely.

because the app label ("auth") and the class name ("User") matched.

and contrib.auth.models was getting imported before your module.

Oh, what a tangled web we weave, when first we practice evil metaclass tricks.

:)

Yeah, I've touched on metaclasses before, but I completely skipped on the fact that the __new__ method is responsible for returning the newly constructed class, and it can return whatever it wants

Yep, we can do all kinds of awful things by taking advantage of that.

Haha

I used it to enforce some interfaces

hey, i'd like to stop using the django test server and start using nginx to proxy to gunicorn or something and also serve the static content separately

do i have to use collect-static every time i make a change to the static files, or is there some way to have that occur automatically?

So guys, I wrote a nice piece of code for myself which introduced an easy to use functionality on the ModelAdmin, and was pretty helpful to me. It makes it possible to set a widgets dictionary on the ModelAdmin which return widgets for fields, like on a Form. I know formfield_overrides already does that, but that was not scallable enough for me and uses db_fields instead of field names. Now I'm wondering if I should start a discussion about

it somewhere so something similar might land in Django. Should I start a topic on the django-developers mailing list or something? It's not that clear to me where the appropiate place is for presenting something like that

still stuck with uwsgi, has anyone ever seen a "relative imports require the package arg" error thrown by uwsgi? https://gist.github.com/AntelopeSalad/8742598

AntelopeSalad: What is ROOT_URLCONF set to?

btw for the record, if i run the server with runserver i can access that url without issues

if I have an {% if ... %} bit and want to break it up into multiple lines before the closing %}, how would I do that?

At the moment, I get a syntax error for the endif if I put the "if" in two lines

Oh, it's only a certain URL? Okay, then can you paste your urls.py?

mattmcc: ROOT_URLCONF = '{0}.urls'.format(PROJECT_NAME)

well, it's the only url in my app for the most part

it's only when i try to access any page with uwsgi too, runserver works for everything

Synthead: sounds like you're putting too much in that if :)

Synthead: The template parser doesn't support that.

Synthead: if you find your logic is getting that complicated, it might not be a bad idea to compute it in your view...

Synthead: can you move it to a model method?

right, yes

anyone who works with celery?

mattblack123: sure, whats up?

seanbrant I followed the tutorial and if I use runserver I can get celery to work, but when I start into the prod env (gunicorn+nginx) I got the following error: ImportError: Could not import settings 'dunning_cruncher.settings' (Is it on sys.path? Is there an import error in the settings file?): cannot import name Celery

mattblack123: do you have a celery.py file in the root of your project?

yes, I created celery.py, modified __init__,py and created tasks.py

mattmcc: is there anything else i can supply to the gist to help fix the situation?

AntelopeSalad: Your urls.py?

mattblack123: do you have "from __future__ import absolute_import" at the top of your celery.py?

yes, I'll paste you in a sec celery.py

mattmcc: for the app or the project?

AntelopeSalad: Both.

seanbrant: https://dpaste.de/FwAv