Moving auth and core models to contrib -- and dependencies
Adrian Holovaty
installation, effectively removing the "django-admin.py init" command
and requiring people to install "core" and "auth" explicitly.
Reasoning: It's messy for the framework to create database tables that
everybody doesn't necessarily use. For instance, if somebody doesn't
use the admin or need support for users, the auth app is completely
unnecessary. Sames goes for the stuff in the "core" app. I have seen
this criticism come up from a couple of people.
However, we shouldn't make it any harder to get started using Django
-- and having to install "core" and "auth" would require extra steps
that aren't currently necessary. So a solution that Jacob and I came
up with is introducing app dependencies. The admin app, for instance,
is dependent on auth and core. The auth app is dependent on core.
There are many apps in Ellington (the World Online commercial CMS
built on Django) that depend on other ones.
A dependency system would solve two problems:
* Having to know which order to install things in.
* Having to install all the dependencies before you install an app
(e.g. installing auth before admin).
Hence, instead of the tutorial saying "django-admin.py init", it would
say "django-admin.py install admin", which would automatically install
the auth app and anything else that's needed.
So how is this implemented? The simplest way we could do it is a
__dependencies__ variable in the __init__.py of the app. For example,
this would go in django/contrib/admin/__init__.py:
__dependencies__ = ('django.contrib.auth',)
(This assumes auth gets moved to django.contrib.auth rather than being
special-cased in django/models.)
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Jeffrey E. Forcier
would be immensely useful on its own merits regardless. For example,
I'm using Django to write a lot of custom business logic for an
intranet, and I've already run into the dependencies issue; being
able to explicitly state them and have django-admin take them into
account would save me a *lot* of headaches.
Regards,
Jeff
--
Jeffrey E. Forcier
Junior Developer, Research and Development
Stroz Friedberg, LLC
15 Maiden Lane, 12th Floor
New York, NY 10038
[main]212-981-6540 [direct]212-981-6546
http://www.strozllc.com
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No right to
confidential or privileged treatment of this message is waived or lost
by any error in transmission. If you have received this message in
error, please immediately notify the sender by e-mail or by telephone at
212.981.6540, delete the message and all copies from your system and
destroy any hard copies. You must not, directly or indirectly, use,
disclose, distribute, print or copy any part of this message if you are
not the intended recipient.
Maniac
>I've been wanting to make the "core" and "auth" models optional for
>installation, effectively removing the "django-admin.py init" command
>and requiring people to install "core" and "auth" explicitly.
>
>
I'd say I'm against it. I don't know of any stats but my feeling is that
removing them would annoy more people with explicit installation of very
common parts. These preinstalled things also help to show new users what
Django can do, not everyone read docs.
Another thing that really scares me: you create a common case of a
default Django app without an admin, hiding very great (should I say
unique?) feature and big selling point.
>However, we shouldn't make it any harder to get started using Django
>-- and having to install "core" and "auth" would require extra steps
>that aren't currently necessary.
>
A single 'init' call for a framework seems reasonable necessity. And
those extra steps anyway will be needed when your app outgrows tutorial.
> So a solution that Jacob and I came
>up with is introducing app dependencies.
>
But this idea is just great! +1
>Hence, instead of the tutorial saying "django-admin.py init", it would
>say "django-admin.py install admin", which would automatically install
>the auth app and anything else that's needed.
>
>
One more thing: general 'init' has another semantics. It's a framework
installation instead of some core app installation. So if later we'll
want to make some other initialisation things it would look more natural
under 'init' than 'init something'.
hugo
>up with is introducing app dependencies. The admin app, for instance,
>is dependent on auth and core. The auth app is dependent on core.
>There are many apps in Ellington (the World Online commercial CMS
>built on Django) that depend on other ones.
+1
The INSTALLED_APPS should still be explicitly name all apps you are
depending on? Or will users be able to just list django.contrib.admin
and the other stuff will be installed, even though it's not named in
INSTALLED_APPS?
Oh, and possible orderings in INSTALLED_APPS should be respected, as
much as possible - so please only move depending apps up in the chain,
but don't change the rest of the ordering - because order in
INSTALLED_APPS gives the order of elements in the admin index.
bye, Georg
Robert Wittams
> So how is this implemented? The simplest way we could do it is a
> __dependencies__ variable in the __init__.py of the app. For example,
> this would go in django/contrib/admin/__init__.py:
>
> __dependencies__ = ('django.contrib.auth',)
>
> (This assumes auth gets moved to django.contrib.auth rather than being
> special-cased in django/models.)
As always with a simple feature, it gets you thinking about possible
complexities...
Eg. The admin_log functionality could be switched over to use signals,
and therefore be totally optional, or replaceable. How would this be
expressed?
With auth, I can see different security systems in future that depend on
user and group, but not the current permission tables. How could we
express this?
Daniel Poelzleithner
> So how is this implemented? The simplest way we could do it is a
> __dependencies__ variable in the __init__.py of the app. For example,
> this would go in django/contrib/admin/__init__.py:
>
> __dependencies__ = ('django.contrib.auth',)
>
+1 for dependencies, but not so simple. Imagine what will happen when
django 1.0 is released and apps are starting poping up. On app may
require a specific version of another app, or is incompatible with a
specific app.
Apps sould define a __version__ in __init__.py wich sould be checked on
the dependencies check.
maybe a syntax like:
__dependencies__ = (('django.contrib.auth',
">=0.1,!=0.2"),('my.app.bla', "==0.3"))
would require a version of contrib.auth that is greater as 0.1 but not
0.2 and version 0.3 of bla :)
kindly regards
daniel
Joseph Kocherhans
Apps sould define a __version__ in __init__.py wich sould be checked on
the dependencies check.
maybe a syntax like:
__dependencies__ = (('django.contrib.auth',
">=0.1,!=0.2"),('my.app.bla', "== 0.3"))
would require a version of contrib.auth that is greater as 0.1 but not
0.2 and version 0.3 of bla :)
kindly regards
daniel
I knew this would come up. :) Packaging and versioning and dependencies are hard. I'm -1 for django doing any type of dependencies/versioning by itself. Writing yet another package manager shouldn't be on django's todo list. Including half-assed package management will probably just cause headaches. I'm not all that familiar with setuptools/easyinstall, but could it help out here?
Joseph
Ian Holsman
ok.. call me old and grizzly here, but I'm still not sold on the point.
having tables which people might not use isn't such a big deal. (it
isn't like they take up so much space, or present a risk)
ease of use is important to me. how will any of this make django
easier to use/faster to develop with?
how will moving auth make it easier to use? the only benefit I can see
is that people could replace the auth system with something else (say
a ACL-based one).
we then would get in the situation where people implement their own,
the problem with that is that it makes sharing apps harder, as each
auth package might do the basic stuff differently
(case in point both hugo & I have implemented tagging.. both do the
same kind of thing. but all the other apps we develop use our own
tagging stuff.. and we're both happy as it does what we want but if
someone else came and tried to reuse things from both projects they
are stuck). I think splitting auth&core will do the same thing at a
larger scale.
--Ian
--
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
Dan Watson
installing them is just as simple as running init and installing the
admin app is now, what's the big deal? For those who want it, it's no
harder, and you'd be able to install the admin without even realizing
you're installing the core and auth models. But for those who don't
want it, you're stuck removing them by hand.
Also, having tables which aren't being used may not be a big deal to
your average user, but in a situation where you want to implement a
django application over an already existing database, especially in a
corporate environment, having pointless tables may not be an option.