DjangoBot: #django-dev

we have used nfa-fixed keyword to be tagged in the merge commit

mrts: what brosner said

right, already marked #565 as nfa-fixed

RaceCondition: is #7141 ready with the latest patch?

telenieko: yeah, more or less

Ok, committing it then ;)

(it actually needs minor stylistic improvements, but it's better to get it in)

I knew that one...

I can't edit global_settings.py xD

mrts: what improvements do you have in mind?

Any commiter around there please checkin the changes in global_setting.py from #7141 :o)

I'm willing to make those improvements

RaceCondition räägime eraldi

yeah, OK, let's talk in private

oops, sorry

I've forgot the IRC syntax

Time to go home, see you later

Hi, all.

deryck: welcome :)

thanks! :)

jacobkm: there are several tickets related to model validation (#1021, #702), should we create a keyword for them? They can't be marked as duplicates of #6845 as they describe various corner cases that can be easily missed by model validation patch.

mrts: yeah, just wanna tag them "model-validation" or something?

cramm: Yeah, with a gigantic bubble floating around malcolm

cramm: kick ass link :)

r.e. http://code.djangoproject.com/wiki/VersionOneRo... - I for one applaud the big ass-party

I'm concerned about the many, many developers who have built existing applications against trunk and hence won't be able to easily upgrade to 1.0 due to backwards compatibility

they kind of end up in limbo - they won't have a "supported version" that gets security updates etc

SimonW: djangopeople?

empty: djangopeople won't be at all hard to upgrade to 1.0 - in fact probably won't need any extra work above defining a couple of ModelAdmin classes

I'm more worried about people who have done extensive customisation to the current admin

SimonW: sorry I meant it's down. :)

<fixing>

SimonW: you're right though.

something is not healthy about that server...

Out of memory: kill process 15171 (mysqld) score 32239 or a child

SimonW: I'm planning on keeping the old admin around somewhere (as a branch or something) for people who need it to check out and use. No maintanance, obviously, but there's no real harm in offering "oldadmin" and "oldforms" to people who can't quite swing a full upgrade.

SimonW: yay OOM!

force restart

oh mysql there's the prob. :P

I probably need to tweak it's settings a bit then

jacobkm: I don't think oldadmin that will work though, as we'll have killed off all of the list_display etc. Model arguments

hmm... actually no, the inner Admin class should still be fine

yeah, it'll just not do anything.

but the nasty crufty admin-related arguments to things like CharField will break

especially the inline ones

actually they are still lingering around. there are some kwargs that have been removed but not all

actually that's something we've been talking about at work recently - it would be useful if there was a supported way to add arbitrary metadata to model fields

if someone cares enough to want oldadmin around, they can step up and make it work; otherwise I don't care all that much.

SimonW: oh, man, tell me about it... post1.0 it's gonna have to be, tho

For now field subclasses work OK.

a model field metadata mechanism could be used to keep the current admin cruft arguments working

tbh I have no idea if this would be a problem or not - need to ask people who have major dependency on existing admin + their customisations (if such people exist)

good night ;)

djangopeople is back up

brosner: Is there anything nows RFC about #6718 ?

not*

i rather spend some time about *why* this happening. i haven't done so yet

if someone knows or wants to spend that time for me. please do :)

I'll look through and see if it's a circular error as the report suggests, or an already registered issue

i think it is, but i want to see if there is a better fix

Is which?

the former

Yeah, it's a circular import issue

where does it start?

Here's the chain, admin site imports logout from views, views imports AuthenticationForm from forms, forms imports User from models, models imports admin.py, which imports admin

And the admin imports UserCreationForm(from forms)

any feedback on #6587 ?

its that dang admin view in views.py i bet

No, sites.py imports UserCreationForm at the top, which causes the problem I think

oh i see

then the patch there would be the most sensible

let me look real fast

Alex_Gaynor: it does?

oh authenticate and login?

Err, yeah , right

have you been able to reproduce it?

Whoops, admin.py imports the Form, my bad

The loop is actually exlusively within auth

forms imports model, imports admin, imports form

haha

Ok, yeah, I'm right this time :D

ok yes

you are

:)

its either we do what the patch does or remove that models.py import

There was some discussion of having admin.py automatically get imported at runtime to avoid the user needing to do that, what happened with that?

it would be manual anyways

i am just going to fix it as is for now.

It seems we'll need to find a general convention for this, because it certainly isn't a single usecase scenario

Alex_Gaynor: maybe you were gone, but read the logs for this channel