DjangoBot: #django-dev

jezdez: http://groups.google.com/group/djangocon-organi... -- it's members-only just to keep s/n high, but I've no problem with people joining it if they wanna help out.

oh sure, I've been talking with people here organizing a one or two day workshop so I'm definitely interested

jezdez: yup, that's the idea behind the list :)

great :)

jacobkm: I owe you some diffs from the doc refactor sprint btw :) they are almost finished and need to be proofread -- will work on them over the weekend

sweet

#3591

yeah good one thnx :)

Newmaniese: got a second?

Sure what's up

i am looking at #6776 again and am not liking the use of a metaclass

yea there be dragons

so i am thinking about just doing an automatic import of admin modules in INSTALLED_APPS

i never did like having people use __init__ to import admin

brosner: I'd really like [__import__("%s.admin" % app) for app in INSTALLED_APPS)]

yeah thats what i just wrote. one sec

I'm pretty sure I got a grudging +0 from Adrian, too, so I'd say just do it.

brosner: only thing about that is it kinda ruins the whole multiple admin thing

Another option is a AdminSite.autodiscover() method. You could call it from urls.py, maybe.

(Dunno about that second part, but...)

I think I'd prefer an explicit autodiscover() call, but figuring out where it'd get called is a bit annoying.

jacobkm: Adrian gave a +0 as long as it was optional iirc

What about an admin.py in project root where you can define apps that should be in the admin and different admins

jkocherhans: yeah, I think so

Newmaniese: you can't count on there even being a "project" -- that's sorta a starter concept, anyway.

i.e. most advanced users don't use 'em

I was thinking next to settings

brosner: yeah

autodiscover sounds good to me

so then some docs about the multiple import paths?

yeah

brosner: have you been able to duplicate my mod_python bug?

i haven't. i also dont use mod_python. but nothing has cropped up in mod_wsgi

Yea, the logout ticket is an example of it in auth. It's messy and con only happen in mod_python

I have tried in runserver mod_wsgi with the same setup and it only occurs in mod_python under really certain circumstances

it doesn't occur with controled import time, so an autodiscover will fix it. Anything that imports the admin from the models is where it causes problems

FYI that ticket is #6718

jacobkm: http://dpaste.com/56324 <-- then the call could be from django.contrib import admin ; admin.autodiscovery() in a urls.py.

yeah

I kinda don't like it in urls.py, but whatdayagonnado?

yeah i have that same dislike

Well, looks like we've got two options:

(a) have admin.autodisocover (clean) but call it from urls.py (dirty)

(b) autodiscover automatically (dirty)

We could easily turn off autodiscovery with a setting, but that only makes it slightly less gross.

Hrm

somewhere, somehow, we're import for side effects (which I think is what's really causing the eeew) the only other choice I see is 'dotted.paths.in.strings' style config

s/import/importing/

jkocherhans: exactly

so what would Django do? (obviously not invent ZCML again :) )

ugh, need to head to bank be back in a few

fwiw we have the same problem with signal registration

wouldn't that be a good thing to put in a generic App() class, side by side with app_label and verbose_name and other app centric options?

let's not make this a bigger deal than it is

yeah, I didn't put that out there as an "oh shit, let's fix this" more of a "maybe someone has an idea that we haven't thought of yet that might go somewhere"

putting it in urls.py is fine w/ me

I say boo

I think I'd learn more towards automatic autodiscovery with a setting to turn it off.

would that setting kill the autodiscovery for all apps? I mean would I be able to specify which apps to leave out?

any reason why PhoneNumberField inherits from IntegerField?

I see that PhoneNumberField overrides everything that is implemented by IntegerField...

and, OTOH, phone numbers are stored as varchar on all backends

have I missed something?

I'd rather have autodiscovery at an app level as well, but maybe global for now and app specific overrides once the App class stuff lands?

yes, that's the best option, you are right

i'd say lets go with option a for now. it solves the problems we have seen and we can expand on it once app class stuff lands.

actually a setting might make more sense now that i think about it

jezdez: jkocherhans once App class jumps into existence, there is no need for any autodiscovery, it could just be an "initialize" method on it

for now, why don't we just autodiscover something neutral (like module called discover_me.py ;) ) so that it's not admin-specific... we have bunch of stuff that needs this - signals, logging settings, some app-specific initializations etc.

btw. sorry to jump in the middle of a discussion, but remembering how we talked about the exact same thing in chicago I couldn't resist

yeah I also remembered and jumped in the discussion :)

s'ok. I missed out on that discussion.

jkocherhans: you can't do it in URLs - some apps don't have urls.py but want to use admin (or signals, or whatever)

so basically a place to put all the imports for side-effects for your app?

jkocherhans: exactly

and once the App class is here, we would move it there (with the default being importing that very module that we can now choose to autodiscover)

I have a quick question: if I have an app, call it profiles and have 2 sites that use it but I only want one to have it in it's admin how will that work?

Newmaniese: 2 different settings files. nothing special.

well, but with the autodiscover as global option it would either be all apps or none

jkocherhans: did i miss something, is the autodiscovery coming from the installed apps?

That is worse then what exists now

in NFA

Newmaniese: you would have to either not use autodiscover at all, and do it as you would now, or in the discovered module check for the site_id and not register it in some cases

Honza: sounds a little messy, but doable

right now I do all my imports in the root urls.py

which isn't much better

Newmaniese: I am afraid that the clean solution here is known, but feared - its the App class ;), the rest is more or less hackish... or at least that's how I see it, if anyone can think of another clean solution, please share

I fully stand behind the things we discussed at pycon, see http://code.djangoproject.com/wiki/InstalledApp...

but I think jacobkm and brosner looked for a fast solution

Is it doable in this timeline?

what about a decorator on the app

jezdez: I see...

so it can be developed now, wrapped around something else (autodiscovery) and when the app class hits you just move it to that