Re: Virtualenvs and editing contrib stuff manually

[Babatunde Akinyanmi]

No you won't be smitten.

As for isolating your edited django, you can do that but then you
would have to be responsible for improving the code base by yourself.
Also, your edit might inadvertently break django or introduce bugs
that you might find difficult to trace and solve or that might change
some of the logic required to make django work.

On 9/27/12, Chris Pagnutti <chris.p...@gmail.com> wrote:
> Hi. First-time poster here. Feel free to point out any rules I'm not
> following.
>
> I've been looking around for how to make the django.contrib.auth User
> classe's "email" field to be unique and required. There are bunches of
> ways to do it, but it's just soooo darn easy to go into the source and
> change how the field is defined.
> e.g. email = models.EmailField(_('email address'),unique=True)
>
> But in my searches, I've read warnings that you should not do this. The
> reason, if it is given, is that you'll break your app if you update the
> contrib packages. But what if I work in virtualenvs and just leave the
> django version and packages intact for that particular app in that
> particular environment? What are the other practical and philosophical
> reasons for NOT editing the contrib source? Will I be smitten from the
> django community if I do so?
>
> Thanks to all.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/YX9X8u9mdbwJ.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

--
Sent from my mobile device

[Russell Keith-Magee]

On Fri, Sep 28, 2012 at 2:02 AM, Chris Pagnutti

<chris.p...@gmail.com> wrote:
> Hi. First-time poster here. Feel free to point out any rules I'm not
> following.
>
> I've been looking around for how to make the django.contrib.auth User
> classe's "email" field to be unique and required. There are bunches of ways
> to do it, but it's just soooo darn easy to go into the source and change how
> the field is defined.
> e.g. email = models.EmailField(_('email address'),unique=True)
>
> But in my searches, I've read warnings that you should not do this. The
> reason, if it is given, is that you'll break your app if you update the
> contrib packages. But what if I work in virtualenvs and just leave the
> django version and packages intact for that particular app in that
> particular environment? What are the other practical and philosophical
> reasons for NOT editing the contrib source? Will I be smitten from the
> django community if I do so?

Will this approach work? Yes. Ish. :-)

All you're really proposing is a fork of Django. That approach can
certainly work; the downside is that you have to maintain the fork by
yourself.

The good news - as of 2 days ago, Django's trunk has a way for you to
change the User model in an official manner [1]. These changes will be
in Django 1.5, due for release at the end of the year.

If you need a solution *right now*, there was a thread on django-users
a couple of days ago that discussed almost exactly this problem; a
couple of alternate approaches were suggested [2].

[1] https://docs.djangoproject.com/en/dev/topics/auth/#customizing-the-user-model
[2] https://groups.google.com/d/topic/django-users/bPCCAK8x8ig/discussion

Yours,
Russ Magee %-)

[Chris Pagnutti]

Right on.  Thanks for your replies.  Since my change to the contrib.auth.User class is so minor, I'll just make a note of it and wait for the official release of 1.5.

So, with the official way of changing the User class, in order to make different "kinds" of users, would you just use groups and permissions?

[Russell Keith-Magee]

On Fri, Sep 28, 2012 at 10:04 PM, Chris Pagnutti
<chris.p...@gmail.com> wrote:
> Right on. Thanks for your replies. Since my change to the
> contrib.auth.User class is so minor, I'll just make a note of it and wait
> for the official release of 1.5.
>
> So, with the official way of changing the User class, in order to make
> different "kinds" of users, would you just use groups and permissions?
>

It's entirely up to you and your needs. If your "kinds" are
group-like, and it's possible for people to be in different groups,
then using groups might be appropriate. If it's as simple as "this
person is type X OR Y OR Z, then adding a choice field to your user
model may be appropriate.

The point is that in 1.5, your user model is entirely under your own
control. If you want your user to be compatible with Django's login
forms, or more importantly, the admin, there are some requirements you
need to meet, but these aren't too onerous.

Yours,
Russ Magee %-)

[Chris Pagnutti]

Hi.  Thanks to everyone again for your replies.  I've just been wondering, are there any reasons not to subclass the User class to add extra fields to a custom "User", versus the Foreign key method?

On Thursday, September 27, 2012 4:13:34 PM UTC-4, Tundebabzy wrote:

[Russell Keith-Magee]

Hi Chris,

Why pick one over the other? Two potential reasons spring to mind:

1) Foreign keys aren't free, so if you're going to be using the extra
data field a lot, you can save yourself some database load (and some
syntactic cleanliness).

BUT

2) If you get in the habit of just putting everything on your custom
User model, you may find that your User models become very heavyweight
and not especially portable between projects. The portability of the
User model itself may not matter, but it will affect any model that
uses your User model - the more you attach to User, and the more code
that depends on those attachments, the harder it will be to reuse code
that depends on those attachments.

There's a balance between the two to be struck, which will ultimately
be driven by your own usage patterns more than any generic advice.

Yours,
Russ Magee %-)

> https://groups.google.com/d/msg/django-users/-/KYZyzsq4H4IJ.

[Chris Pagnutti]

Hey thanks Russell.  That's a great explanation.  Is there a particular reason that the docs tend to favour the foreign key method over subclassing?

On Thursday, September 27, 2012 4:13:34 PM UTC-4, Tundebabzy wrote:

[Russell Keith-Magee]

It's mostly historical - the foreign key method was the *only* method
until about a week ago. :-)

The development docs contain a section about how to set up your own
User model, but that section isn't the 1.4 (current stable) docs. If
you can point me at a section in the dev docs that you think
recommends the foreign key method, it probably needs to be rewritten
or rephrased given the new features that have landed.

Yours,
Russ Magee %-)

> https://groups.google.com/d/msg/django-users/-/kgPJcEQC1vAJ.

[Chris Pagnutti]

Hi Russel.  Thanks again for your help.  I guess "recommend" was the wrong word to use.  I just mean it's how the docs tell you to do it.

https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users

But instead of doing it this way, I just created a new class like this

class MyUser(User)

with all the additional fields I wanted, which allows me to use all the auth stuff for logging in etc. and it seems to make forms easier.  It just felt cleaner at the time, but the more I think about it I wonder if there might be a reason why this might be bad practice. For example, I don't like how creating a new MyUser object makes duplicates in the "MyUsers" and "Users" sections of the admin.  I haven't tried it, but it seems to me this will still be the case if I were to use the foreign key method.

What I was trying to do was have Users for the site administrators, and MyUsers for site "members", while still taking advantage of all the built-in contrib.auth stuff.  I would think that this scenario is common enough that there is a standard way of dealing with it.

On Thursday, September 27, 2012 4:13:34 PM UTC-4, Tundebabzy wrote:

[Russell Keith-Magee]

On Sat, Oct 6, 2012 at 10:17 AM, Chris Pagnutti
<chris.p...@gmail.com> wrote:
> Hi Russel. Thanks again for your help. I guess "recommend" was the wrong
> word to use. I just mean it's how the docs tell you to do it.
> https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users

Right - but if you look at the same docs in 1.5:

https://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users

You'll see that the AUTH_PROFILE_MODULE technique is marked as deprecated.

> But instead of doing it this way, I just created a new class like this
> class MyUser(User)
> with all the additional fields I wanted, which allows me to use all the auth
> stuff for logging in etc. and it seems to make forms easier. It just felt
> cleaner at the time, but the more I think about it I wonder if there might
> be a reason why this might be bad practice. For example, I don't like how
> creating a new MyUser object makes duplicates in the "MyUsers" and "Users"
> sections of the admin. I haven't tried it, but it seems to me this will
> still be the case if I were to use the foreign key method.

This is actually *exactly* the same method, just with different usage
syntax. Django implements inheritance using a multiple tables and a
foreign key; it just hides those detail from you. So - all you've done
here is implement a MyUser model with a foreign Key to User - you just
didn't need to define it as such.

> What I was trying to do was have Users for the site administrators, and
> MyUsers for site "members", while still taking advantage of all the built-in
> contrib.auth stuff. I would think that this scenario is common enough that
> there is a standard way of dealing with it.

There is - and this is the situation where using profile models is
possibly the right way to handle things (something that the new docs
possibly need to clarify).

What you need to narrow down is the difference between authentication
and profile. Regardless of whether the user is an admin or a member,
they need to identify themselves to the system. For example, every
user, regardless of whether they're a member or an admin, needs to
have an email address so you can contact them. This information is
what needs to go in your User model.

However, once they're logged in, Members have different data to
Admins. Member- or Admin-specfiic data is what should go on the
profile. Admins may have a contact phone number for emergencies, but
members won't; members may have their birthdays stored, but admins
won't. You can then determine whether a user is a member or an admin
by checking for the existence of the appropriate profile model.

This approach has the additional benefit that an admin can be a member
without needing to change accounts - it's just a user that has both a
member and an admin profile.

Yours,
Russ Magee %-)