Proposal: django.models.core/auth should be regular apps
Joseph Kocherhans
kind of confusing. They should be regular apps, but we don't want to
have to add 2 extra steps (installing the 2 apps) to get a django
project up and running. Here's a few ideas for fixing the problems.
Create 2 new apps, django.contrib.core and django.contrib.auth. Move
the models from django.models.core and django.models.auth into these
new apps.
Change the settings.py template to include core, auth, and admin in
INSTALLED_APPS.
Change django-admin.py init. It should install core, auth, and admin.
Add a django-admin.py init-minimal command. It will just initialize
the django tables, not install any apps. People who want the minimal
setup can just delete the apps from INSTALLED_APPS. They're going to
edit the file anyhow.
We might want to add one more django-admin.py command or flag to
install just core and auth, but I can't think of what to call it. I
don't want to go too far here though, we don't want the number of
django-admin.py commands to explode arbitrarily.
Subproposal: Dependencies
Add pre and post install hooks (or possibly signals). An app's install
hooks can check to see if all dependencies are installed already, and
generate nice error messages if they are not (or maybe even try to
install the dependency automatically). Some convenience functions
should probably be added as well to make the basic case pretty
painless. This has the added benefit of allowing things like the
undocumented loading of files in your app's 'sql' directory to be
added to an app without having to change django.
All of this should be done on the magic-removal branch since a lot of
things are being broken there anyhow.
Comments?
Joseph
Adrian Holovaty
> Treating django.models.core and django.models.auth as special cases is
> kind of confusing. They should be regular apps, but we don't want to
> have to add 2 extra steps (installing the 2 apps) to get a django
> project up and running. Here's a few ideas for fixing the problems.
I did a double-take on this e-mail, because it's almost exactly the
same proposal as one I wrote a couple of weeks ago! :)
That thread died out due to discussion of the problems of a dependency
system -- which seemed like reasonable pushback to me. Let's avoid the
dependency thing for now.
I really like your idea of "init" and "init-minimal" -- that
accomplishes the clean split of auth/core into regular apps while
keeping it just as easy to install the basics. Let's do it!
One more idea, though, would be to split "core" into
django.contrib.sessions, django.contrib.contenttypes and
django.contrib.sites. Packages would go away, because they're not
really necessary (we used them heavily about 1.5 years ago, but
they're no longer useful). Thoughts on that?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Joseph Kocherhans
>
> On 1/6/06, Joseph Kocherhans <jkoch...@gmail.com> wrote:
> > Treating django.models.core and django.models.auth as special cases is
> > kind of confusing. They should be regular apps, but we don't want to
> > have to add 2 extra steps (installing the 2 apps) to get a django
> > project up and running. Here's a few ideas for fixing the problems.
>
> I did a double-take on this e-mail, because it's almost exactly the
> same proposal as one I wrote a couple of weeks ago! :)
>
> http://groups.google.com/group/django-developers/browse_thread/thread/dc86e876af62a4cd/3413fb5e4ec2ed6c
>
> That thread died out due to discussion of the problems of a dependency
> system -- which seemed like reasonable pushback to me. Let's avoid the
> dependency thing for now.
I was actually one who argued against a dependency system, but that
was in reference to some some sort of "blessed" dependency system that
does version checking and everything declaratively. What I'm proposing
here is allowing for doing it procedurally. It would require a lot
less up front design, and wouldn't generate as many "can you make it
do X, Y and Z too!?" type of requests. Those are what I was worried
about. I think the pre-post install stuff would be useful regradless
of using it for dependencies, but it's certainly a separate issue from
splitting up core/auth into apps. Maybe I'll just bring it up in
another thread later.
> I really like your idea of "init" and "init-minimal" -- that
> accomplishes the clean split of auth/core into regular apps while
> keeping it just as easy to install the basics. Let's do it!
I'll start working on a patch for the magic-removal branch. This
should fix #1171 as well.
> One more idea, though, would be to split "core" into
> django.contrib.sessions, django.contrib.contenttypes and
> django.contrib.sites. Packages would go away, because they're not
> really necessary (we used them heavily about 1.5 years ago, but
> they're no longer useful). Thoughts on that?
I always thought sites were something useful for a few special cases,
but certainly not for everyone. Splitting out sessions might be useful
as well since I can see people wanting to replace it. I've never even
really noticied packages, so no comment there.
Joseph
Joseph Kocherhans
> django.contrib.sessions, django.contrib.contenttypes and
> django.contrib.sites. Packages would go away, because they're not
> really necessary (we used them heavily about 1.5 years ago, but
> they're no longer useful). Thoughts on that?
Now that I think about it a little more I agree that core should be split into:
django.contrib.sessions
django.contrib.sites
If no one is using packages I'll just drop it.
contenttypes feels pretty core to me. I guess django doesn't really
depend on it though. (although many apps do.) I think contenttypes
should it go in django.contrib.core? Any preferences?
Also, should the table names stay the same? My vote is for changing
them, and updating BackwardsIncompatibleChanges with insructions on
how to rename them.
Joseph
Adrian Holovaty
>
> django.contrib.sessions
> django.contrib.sites
Sounds good.
> If no one is using packages I'll just drop it.
This is a bit easier said than done...The content-types table depends
on it. How about splitting this patch into several stages --
* Move sessions from core to django.contrib.sessions (and change dependencies)
* Remove Package model (and dependencies on it)
* Move sites from core to django.contrib.sites (and change dependencies)
* Move auth to django.contrib.admin (and change dependencies)
* Move contenttypes to django.contrib.contenttypes (and change dependencies)
* Change django-admin init to install sites, auth, sessions, contenttypes
* Add django-admin init-minimal
What did I miss?
Because this is a multi-step change, and it's much more manageable
(and more easily understood) for commits to be as narrowly-focused as
possible, would you be interested in commit access on the
magic-removal branch? Let me know, and I can send you information
privately.
> contenttypes feels pretty core to me. I guess django doesn't really
> depend on it though. (although many apps do.) I think contenttypes
> should it go in django.contrib.core? Any preferences?
Let's do django.contrib.contenttypes. The only parts that depend on it
are the admin log and any bits that relate an object to another object
+ content type (such as django.contrib.comments, in which a comment is
related to a content_type_id and object_id).
> Also, should the table names stay the same? My vote is for changing
> them, and updating BackwardsIncompatibleChanges with insructions on
> how to rename them.
I agree -- the table names should be changed.
Joseph Kocherhans
>
> This is a bit easier said than done...The content-types table depends
> on it. How about splitting this patch into several stages --
>
> * Move sessions from core to django.contrib.sessions (and change dependencies)
> * Remove Package model (and dependencies on it)
> * Move sites from core to django.contrib.sites (and change dependencies)
> * Move auth to django.contrib.admin (and change dependencies)
> * Move contenttypes to django.contrib.contenttypes (and change dependencies)
> * Change django-admin init to install sites, auth, sessions, contenttypes
> * Add django-admin init-minimal
Should sites be installed by init? I think it's used rarely enough
that it shouldn't. Also, I think init should install admin as well,
but maybe there should be something like an init-noadmin command as
well in that case. It'd be nice to remove a couple of steps from the
tutorials (django-admin.py install admin, add django.contrib.admin to
INSTALLED_APPS), but it's at the expense of people who don't want the
admin, but *do* want sessions, auth, etc.
> What did I miss?
Just updating the settings template so sessions, contenttypes, etc are
in INSTALLED_APPS by default. That's sort of implied in each
individual model move though.
> Because this is a multi-step change, and it's much more manageable
> (and more easily understood) for commits to be as narrowly-focused as
> possible, would you be interested in commit access on the
> magic-removal branch? Let me know, and I can send you information
> privately.
Sounds good.
> > contenttypes feels pretty core to me. I guess django doesn't really
> > depend on it though. (although many apps do.) I think contenttypes
> > should it go in django.contrib.core? Any preferences?
>
> Let's do django.contrib.contenttypes. The only parts that depend on it
> are the admin log and any bits that relate an object to another object
> + content type (such as django.contrib.comments, in which a comment is
> related to a content_type_id and object_id).
Ok.
> > Also, should the table names stay the same? My vote is for changing
> > them, and updating BackwardsIncompatibleChanges with insructions on
> > how to rename them.
>
> I agree -- the table names should be changed.
>
I guess the final step is adding to BackwardsIncompatibleChanges then.
Joseph
Adrian Holovaty
> that it shouldn't.
It's used by various bits and pieces, such as the RSS and redirect
frameworks, that need to know the fully-qualified domain name for an
object. Maybe those frameworks could be slightly refactored to check
that the sites app is installed (see
http://code.djangoproject.com/ticket/1179 ). If the sites app isn't
installed, they could simply use the current domain according to
request.META['SERVER_NAME'].
> Also, I think init should install admin as well,
> but maybe there should be something like an init-noadmin command as
> well in that case.
That gets a bit too specific and special-case-ish. Two choices --
"init" and "init-light" (or whatever it's called) -- is as many as we
should have.
> It'd be nice to remove a couple of steps from the
> tutorials (django-admin.py install admin, add django.contrib.admin to
> INSTALLED_APPS), but it's at the expense of people who don't want the
> admin, but *do* want sessions, auth, etc.
The planned way to do this is to make "django-admin.py install" add
the appropriate line to INSTALLED_APPS by editing the file and adding
an "INSTALLED_APPS +=", like so:
INSTALLED_APPS += 'django.contrib.admin'
That removes the need to edit the settings file to add stuff to INSTALLED_APPS.
Adrian
Ian Holsman
I'm using packages.
I think it is a good place to put stuff like package-specific preferences.
ie.. the preference of the text markup you would like
(bbcode/markup/textile) is stored against the 'text' package.
if you like delicious/furl/digg is stored against the 'bookmark' package.
FWIW.. I'd like to split up the auth package into 2 bits.
- authentication
- use DB, LDAP, openID, whatever
- authorization
- ACLs, current-thing, Karma
so people can easily choose what they want.
--
I...@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti
Joseph Kocherhans
>
> Hi.
> I'm using packages.
> I think it is a good place to put stuff like package-specific preferences.
I'm going to leave them as is for now. There's actually quite a bit
that depends on them that I need to take a closer look at. I'm
starting to think they might be useful for other things as well. Once
I figure out what I think should be done, I'll bring it up here before
I make any changes.
Joseph
Joseph Kocherhans
Did you mean move auth to django.contrib.auth here? Or do you really
want it moved into admin?
Joseph
Adrian Holovaty
> > * Move auth to django.contrib.admin (and change dependencies)
>
> Did you mean move auth to django.contrib.auth here? Or do you really
> want it moved into admin?
My mistake -- I meant django.contrib.auth.
Adrian
Ivan Fedorov
> Hi.
> I'm using packages.
> I think it is a good place to put stuff like package-specific preferences.
>
> ie.. the preference of the text markup you would like
> (bbcode/markup/textile) is stored against the 'text' package.
>
> if you like delicious/furl/digg is stored against the 'bookmark' package.
>
> FWIW.. I'd like to split up the auth package into 2 bits.
>
> - authentication
> - use DB, LDAP, openID, whatever
> - authorization
> - ACLs, current-thing, Karma
>
> so people can easily choose what they want.
+1
Joseph Kocherhans
* Move sessions from core to django.contrib.sessions (and change dependencies)
Done.
* Move sites from core to django.contrib.sites (and change dependencies)
Done.
* Move auth to django.contrib.admin (and change dependencies)
Done. Earlier in this thread, Ian Holsman requested that auth should
be further split into authentication and authorization. Personally, I
don't see a need to do this until support for LDAP, ACL's, or whatever
is added. Comments?
* Remove Package model (and dependencies on it)
Ian Holsman still uses this. I'm things we may want to just change
this to App or Application instead of Package. I can see how it
*would* be useful, although I haven't used it myself. I'll defer to
Adrian and Jacob on this.
* Move contenttypes to django.contrib.contenttypes (and change dependencies)
If Package stays, then should packages and contenttypes both go into
separate apps?
* Change django-admin init to install sites, auth, sessions, contenttypes
init now installs sessions, sites, auth. It also installs the old
django.models.core for now (this will of course be changed once that
module is moved to django.contrib)
* Add django-admin init-minimal
Done. init-minimal still installs django.models.core for now.
* Add sessions, sites, auth, and contenttypes to the default settings template
I'll do this once the issues with packages and contenttypes are
straightened out.
Joseph
Adrian Holovaty
> Here's a status update on moving dango.contib.core/auth into django.contirb:
>
> * Move sessions from core to django.contrib.sessions (and change dependencies)
> Done.
>
> * Move sites from core to django.contrib.sites (and change dependencies)
> Done.
Excellent! Thanks for your work on this. Much appreciated.
> * Move auth to django.contrib.admin (and change dependencies)
>
> Done. Earlier in this thread, Ian Holsman requested that auth should
> be further split into authentication and authorization. Personally, I
> don't see a need to do this until support for LDAP, ACL's, or whatever
> is added. Comments?
No need to split it into authentication and authorization at this point.
> * Remove Package model (and dependencies on it)
> Ian Holsman still uses this. I'm things we may want to just change
> this to App or Application instead of Package. I can see how it
> *would* be useful, although I haven't used it myself. I'll defer to
> Adrian and Jacob on this.
>
> * Move contenttypes to django.contrib.contenttypes (and change dependencies)
> If Package stays, then should packages and contenttypes both go into
> separate apps?
The package model is messy, and I see no reason for it to stick around
in the long term, but fixing that is also messy. :-( So, let's move
packages and contenttypes into a single "django.contrib.contenttypes"
app, and plan to remove packages down the road.
Adrian
Joseph Kocherhans
>
> On 1/8/06, Joseph Kocherhans <jkoch...@gmail.com> wrote:
> > Here's a status update on moving dango.contib.core/auth into django.contirb:
> >>
> > Ian Holsman still uses this. I'm things we may want to just change
> > this to App or Application instead of Package. I can see how it
> > *would* be useful, although I haven't used it myself. I'll defer to
> > Adrian and Jacob on this.
> >
> > * Move contenttypes to django.contrib.contenttypes (and change dependencies)
> > If Package stays, then should packages and contenttypes both go into
> > separate apps?
>
> The package model is messy, and I see no reason for it to stick around
> in the long term, but fixing that is also messy. :-( So, let's move
> packages and contenttypes into a single "django.contrib.contenttypes"
> app, and plan to remove packages down the road.
Done.
The settings.py template has also been updated now.
I think it should be (almost) safe to completely remove django.models
now. I think there's still some code in the comments framework that
uses the old (pre-magic-removal) module syntax. I'll fix it later
today.
Joseph