DjangoBot: #django-dev

Today's patch r9527 added a new dependency on the bz2 module. Do folks think this was intentional (in which case this might be a documentation bug) or unintentional?

mdhancher: it's included with python isn't it?

Hmm, actually you're right, my build of Python just didn't build it for some reason.

mdhancher: some operating systems have a habit of distributing a "python" package that doesn't include the normal Python standard library.

Yeah, but by the look of it this one was my fault (rebuilding Python without bz2 dev libraries), not "theirs".

Gulopine: my advice is just do whatever seems logical.

yeah, i figured

i just sent it in tonight, already

testing

help

I can't see anyone talking in here, including myself.

no one is talking

brosner: do you want me to do any further work on #9493?

you mentioned that once 1.0.1/1.0.2 is out, it may be commited

Hi ho

jacobkm: Wrap help_text in "<span class="helptext"></span>", (needs ticket) -> #8426

also, as the implementation was trivial, I'd say it's ready for checkin

(apart from a review of course)

OK

jacobkm: You an allan sherman fan?

Alex_Gaynor: what kind of Jew would I be if I wasn't?

")

ha

telenieko: do you have a git:// URL for your Django repo, or just the http one? I hate how slow git is over http.

jacobkm: how do you feel about #8193 ? Do you want any further work on that?

jacobkm: is the 1.1 features page supposed to be locked for editing to non-admins?

Alex_Gaynor: no

ok, mind if I fix that then?

Alex_Gaynor: nope, go for it

Has there been any discussion about #4438 besides what's on the mailing list? It seems that discussion seems to keep trailing off....

Essentially this is the most up to date discussion on the subject of dynamic SITE_ID: http://tinyurl.com/6hjy79

kylefox: I guess not, otherwise someone would have posted a link to the discussion on the ml

Hmm, okay.

is there a reason why you can't prepopulate admin form inlines with request.GET? or am I missing something?

Another question, I couldn't find a ticket relating to this: has there been any discussion about making an app's Models "swappable?"

Ex: a way to easily plug my custom User class into contrib.auth

that's been sort of discussed, the consensus isn't especially positive

there's a ticket about it, and it was on the 1.1 features lists that was discussed, but it didn't mkae the cut

Alex_Gaynor: Do you remember the ticket # or description?

what was the opposition?

#3011

the discussing is somewhere in the mailing list, and on jacob's spreadsheet

Hmm. See I think that ticket has the right idea but is short sighted

kylefox: in general, the idea of "let this class pose as that class" is going to get rejected every time -- it smacks of all sorts of overingineering, and it might well be impossible to get right.

I expect the discussion about swapping models has focused on the User largely because in the real-world, that's the model that would need to be swapped most often.

On a historical note, Django used to let you do this. It was the biggest cause of instability in the world, and we dropped it in magic-removal and didn't look back.

jacobkm: Right, I understand that. I suppose the problem is that for our application needs a very different User model, but I don't want to re-write the entire auth app

And I don't want to use get_profile() :/

Why not?

Well....I'm probably going to get told that Django is not the tool for the job....

We're looking at using django to build some SaaS products (please excuse the buzzword ;)

So for example, having a unique username doesn't work for us.

Why not create your own Auth Backend then?

Currently to get around that, our UserProfile has a "username" field and a FK to an Account model

Alex_Gaynor: We've done that also

But that's where things start to get ugly, because we're sort of piggybacking the auth.User model, for no other purpose than using the remainder of the auth app

kylefox: so let's say your auth backend gets to return a custom user object without a unique constraint on the username. How, then, would any of the built-in auth veiws -- nearly all of which key off of or ask for a yusername -- still work?

so we're munging a unique auth.User.username based on their user profile's username and account number

jacobkm: I don't know.

kylefox: here's a hint: they can't.

So, if you get to use a custom user object, you also get to write custom auth views.

It's true.

So now you've rewritten the user object and rewritten the auth views.

What's left in the auth app you get to reuse? A couple of one-line decorators and a 20-30 line piece of middleware.

Right. I suppose what I'm proposing would be along the lines of adding a completely new layer of abstraction to apps

Which probably isn't feasible.

So how exactly is this any different from rewriting the app from scratch again?

Let me propose an alternate scenario:

You write those custom auth views which you'd have to write anyway.

You write that custom User object you have to write anyway.

You write a custom peice of auth middleware that hangs *your* user object off request.user in the same way that the built-in one does.

You user class provides a similar-enough API to the built-in user app that existing things that expect auth continue to work.

And now you get custom auth.

Mmm, some of the built-in auth decorators might not work; dunno about that.

And if you're User object is strange enough, you might have to write a custom ModelAdmin subclass and override the auth parts of the admin to make stuff work.

Right.

This proposal (a) only requires a small bit of code more than this pose-as-a-user business, (b) doesn't require the type of monkeypatching that class posing does, and (c) works right now.

I guess what I'm envisioning would (for example) be a more abstract way of writing the auth views such that they don't explicitly refer to the implementation of the User model included with contrib.auth

ubernostrum: I also *really* like that idea. Unfortunately, if you toss out auth you toss out the admin ;)

That's no longer true.

which is exactly the point I'm getting at

kylefox: that's not true; like I said you can write a custom ModelAdmin that overrides the auth stuff.

Once again it's a bit of work to integrate your own auth scheme into the admin, but it's certainly doable.

Just not documented at all.

That's very true i suppose....

People wouldn't believe the shit you can do with the admin these days.

kylefox: also, you might want to take a close look at the auth views; they don't even import anything from django.contrib.auth.models... they're probably a lot more flexible than you think.

It is *very* cool alright. I suppose I never really thought about overriding the reliance on contrib.auth.

But frankly if you're going to use a different user you probably want different ways of changing passwords and stuff.

jacobkm: You're correct in that. I've done some digging and I suspect I could reuse a lot of the behind-the-scenes code in contrib.auth for a custom auth app

Okay, well thanks for the insight.