[GSoC] Application Loading
Nick Sandford
====================================
About Me
----------
Hi everyone,
My name is Nick Sandford, I'm an electrical engineering student at the
University of Western Australia.
Background
-----------
I haven't been a particularly active contributor to any open source project -
here is where I hope to change that. In my current work at Christ
Church Grammar School we use Django heavily for most of our internal
projects. I've
followed django-dev closely for a couple of years and I have poked around with
its internals on various occasions.
Plan
-----
Implement an improved application loading mechanism into Django.
Rationale
---------
Django current application loading code is inflexible in many cases. There
exists a need for a number of extra features to be added to the way
applications are handled such as:
* The ability to internationalise application names.
* The ability to customise application names similar to ``verbose_name`` in
``model._meta``
* Deploy the same application multiple times in a single project.
* Deploy two different applications with the same name.
* Manage settings within applications.
Method
-------
I don't intend to solve the third dot point of the previous list - it seems
like a difficult problem, possibly to be tackled post-GSoC. What I do intend
to do is to move towards 'application classes' more akin to
``django.contrib.admin``.
New syntax in ``settings.INSTALLED_APPS`` will be introduced to address the
previous issues. Some examples of accepted syntax:
.. sourcecode:: python
INSTALLED_APPS = (
'django.contrib.auth',
app('blog.BlogApplication', 'blog_1', 'My blog', 'app1_'),
app('blog.BlogApplication', 'blog_2', 'Some other blog', 'app2_'),
app(path='tagging.Tagging', verbose_name='My tagging application'),
app('categories', db_prefix='cat_'),
app({'path': 'django.contrib.admin.AdminApplication',
'label': 'admin',
'verbose_name': 'Secret Admin'}),
)
The ``app`` function will take four arguments, three of which are optional.
These are ``path``, ``label``, ``verbose_name``, and ``db_prefix``. It will
return an instance of an ``Application`` object, which will contain all of an
installed application's information. ``path`` will be the dotted path to a
subclass of ``Application``. The downside is that ``settings.py`` requires
an import, which may be against style rules.
.. sourcecode:: python
def app(path, label=None, verbose_name=None, db_prefix='')
if not path or not isinstance(path, basestring):
raise ImproperlyConfigured('Application path must be string.')
application_class = import_module(path)
return application_class(path, label, verbose_name, db_prefix)
``INSTALLED_APPS`` will then be a tuple containing strings or ``Application``
instances. The application loading code will iterate over ``INSTALLED_APPS``
and construct an internal cache of ``Application`` instances to be used with
``get_models``, etc. For backwards compatibility, if an element of the tuple is
a string, an instance of a base ``Application`` class will be created with sane
defaults (similar to ``app_label`` at the moment).
The ``Application`` class will be very similar to ``django.contrib.admin``'s
``AdminSite`` and will hopefully simplify application settings. If you write
views and urls directly on the ``Application`` class itself, instead of an
``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
could just reference ``self.api_key`` for instance. This wouldn't be the
required, just an optional extra.
Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.
I agree with moving ``django.db.models.loading`` to ``core.apps``, since we'll
no longer require applications to have a ``models.py``. A reference to the
new functions in ``core.apps`` will still live in ``django.db.models.loading``
for backwards compatibility.
A subclass of ``Application`` might look like:
.. sourcecode:: python
from django.views.simple import direct_to_template
from djang.core.apps import Application
from blog.models import Entry, Category
class BlogApplication(Application):
models = [Entry, Category]
api_key = 'default'
def entry_detail(self, slug, request,
template_name='blog/entry_detail.html'):
entry = get_object_or_404(Entry, slug=slug)
context = {
'entry': entry,
'api_key': self.api_key,
}
return direct_to_template(request, template_name, context)
Hurdles
--------
There are a list of possible technical issues:
* Introducing the new ``app`` function requires an import in settings.py
which might not be acceptable behaviour.
* Two applications with the same label.
* Worrying amounts of things that may affect backwards compatibility would
probably need addressing.
Solutions
----------
We could alternatively introduce a new file into the project,
``applications.py`` which contains purely application-related setup. This might
be handy to manage application settings and to ensure ``settings.py`` doesn't
get too full of application-specific settings. This could allow us do something
like:
.. sourcecode:: python
from django.core import apps
from blog import BlogApplication
class MyBlogApplication(BlogApplication):
api_key = 'testing'
another_blog = BlogApplication(label='blog2',
verbose_name=_('Another blog'),
api_key='anothertest')
apps.register(MyBlogApplication, label='blog', verbose_name=_('My blog'))
apps.register(another_blog)
depending on what people would like more. This could allow us not to touch
``settings.INSTALLED_APPS`` at all.
To solve the 'two applications named auth' problem, the ``AppCache`` keeps
track of application instances, not ``app_label``. For the case of two
applications with the same name, ``get_app`` should return a tuple containing
both application instances with that name. To ensure a single application
instance is returned with ``get_app``, another argument - ``path`` should be
added. ``get_models`` and ``get_model`` would take an application instance
and return models on that instance. This might affect the admin's handling of
applications.
Timeline
---------
1) Implement the ``Application`` class. -- 2 weeks
2) Move ``django.db.models.loading`` to ``django.core.apps`` and refactor
``get_app``, ``get_model``, etc. -- 1 week
3) Modify the admin, management, translation, templatetags, templateloaders
to use ``app.path`` -- 1 week
4) Testing and documentation -- 3 weeks
5) Bug fixes and backwards incompatibility problems -- 1 week
6) Time permitting possibly tackle the multiple instances of the same app
problem. (about 2 weeks).
Any feedback would be greatly appreciated, sorry for the late application and
good luck to all the other applicants :)
Thanks,
Nick
bur...@gmail.com
I don't like your application creation syntax (why using dict-based
DSL instead of class-based?), but
I like how you approach the overall problem.
More than that, you have shown you do understand all the problems
you're going to solve, and that you have design skills required for
solution.
But I believe you can do even further with your proposal.
You said:
>Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.
This is very nice idea, and I think, it allows to come with further
design of how should multiple app copies work.
I don't want to push on you, or suggest a working solution, so I'd
like to see your ideas.
I've got questions that might help:
* how will views know about their current application?
* how will views get their app settings after your changes?
* is it a good idea to make urls properties (namespace, app_name)
correspond with the same application properties?
Currently options are either "from django.conf import settings", and
those settings are singleton with configuration options, or put into
urls.
Should we say "go away" to view-as-a-function and go to rails-like
controllers like your Application class?
(I'm for this option actually, all views other than "hello world"
always take such a bloat of configuration options right now that needs
to be put into controllers anyway -- look at django.contrib.auth.views
for example!)
(Completely unrelated note, but I'd rather see a url routing right
near those views definition after update. because, 98% of times, you
won't need urls at all!)
Please also see the thread
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879?hl=en,
there's a question you avoided delicately, about what to do with
ForeignKey. It might also help.
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Vinay Sajip
already? Would you be using it as a starting point?
Regards,
Vinay Sajip
Nick Sandford
>
> Hi Nick,
>
> I don't like your application creation syntax (why using dict-based
> DSL instead of class-based?), but
> I like how you approach the overall problem.
> More than that, you have shown you do understand all the problems
> you're going to solve, and that you have design skills required for
> solution.
> But I believe you can do even further with your proposal.
>
> You said:
> >Model classes will get a ``_meta.app`` attribute, which will be an instance
> of the model's ``Application`` class. Models should only be associated with one
> application.
> This is very nice idea, and I think, it allows to come with further
> design of how should multiple app copies work.
> I don't want to push on you, or suggest a working solution, so I'd
> like to see your ideas.
Multiple app copies is quite a bit more difficult, unless you assume
(like the admin)
that they use the same database table. Then I guess you could store multiple
application instances in Model._meta.app and use url namespacing to
differentiate
applications/views.
>
> I've got questions that might help:
> * how will views know about their current application?
Views implemented in views.py wouldn't necessarily need to know about their
current application, but if they did, you could use get_app("my_app")
in the view itself.
Views implemented on the Application itself wouldn't have this problem.
> * how will views get their app settings after your changes?
For settings still in settings.py, just the same as always.
For settings implemented in an Application itself maybe something like:
# views.py
def view(request):
api_key = get_app("my_app").options.api_key
# do stuff
and for views in an Application:
def view(self, request):
api_key = self.options.api_key
# do stuff
> * is it a good idea to make urls properties (namespace, app_name)
> correspond with the same application properties?
That would help for the case of multiple application instances, but
for the time being
isn't strictly necessary. Probably not a bad idea to promote.
>
> Currently options are either "from django.conf import settings", and
> those settings are singleton with configuration options, or put into
> urls.
>
> Should we say "go away" to view-as-a-function and go to rails-like
> controllers like your Application class?
I don't think I necessarily want to force people to do that, but
rather make things
easier to be done like that. View-as-a-function still works well for
simple setups.
>
> (I'm for this option actually, all views other than "hello world"
> always take such a bloat of configuration options right now that needs
> to be put into controllers anyway -- look at django.contrib.auth.views
> for example!)
>
> (Completely unrelated note, but I'd rather see a url routing right
> near those views definition after update. because, 98% of times, you
> won't need urls at all!)
That would be pretty nice, you could do something like:
# urls.py
from django.conf.urls.defaults import *
from django.core.apps import get_app
urlpatterns = patterns('',
(r'^blog/', include(get_app("blog").urls)),
)
>
> Please also see the thread
> http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879?hl=en,
> there's a question you avoided delicately, about what to do with
> ForeignKey. It might also help.
As far as I see that, it's more about what to do when you have two
instances of the
same application, which I won't be attempting to solve. With just a
single instance,
models work just the same as they always have (save for the _meta.app) stuff.
Thanks for the feedback.
Nick Sandford
On Fri, Apr 9, 2010 at 5:21 AM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:
>
>
> Have you looked at the patch on ticket 3591 which does some of this
> already? Would you be using it as a starting point?
You've taken the route of assuming applications won't know their models until runtime, I've expected that people explicitly assign models to apps.
Your loading code looks like a good starting point also.
Cheers,
Nick
Russell Keith-Magee
> An App Loading mechanism for Django
> ====================================
>
> About Me
> ----------
> Hi everyone,
>
> My name is Nick Sandford, I'm an electrical engineering student at the
> University of Western Australia.
>
> Background
> -----------
>
> I haven't been a particularly active contributor to any open source project -
> here is where I hope to change that. In my current work at Christ
> Church Grammar School we use Django heavily for most of our internal
> projects. I've
> followed django-dev closely for a couple of years and I have poked around with
> its internals on various occasions.
Ok - I clearly need to get a Perth DjUG going...
I'm not necessarily sold, but this is certainly an interesting idea.
In some respects, it's a variation of a suggestion that Jannis made in
another thread. Jannis suggested that we use dotted notation in
INSTALLED_APPS to point at the application instances. A registration
process is certainly another novel way of approaching the problem.
My concern with using a registration process is that we could end up
with a situation where INSTALLED_APPS no longer contains a useful
description of what is installed. The interaction between
INSTALLED_APPS and an app registration process also needs to be
considered carefully:
* Does ordering matter? If so, which takes precedence -
INSTALLED_APPS or registrations?
* Are registered apps added to INSTALLED_APPS as part of the
registration process?
* Is this something that needs to be handled as a
"APP_LOADER='django.core.apps.loader.legacy'" which uses
INSTALLED_APPS, and
"APP_LOADER='django.core.apps.loader.registration'" which uses the new
approach (i.e., that new projects won't need an INSTALLED_APPS
setting)?
There are two related subproblems that are also worth investigating here:
* The "Stuff that needs to happen when a Django server instance
starts" problem - you're introducing a new task that needs to happen
at startup. This isn't the only 'on startup' task - admin
registration, signal registration, and the proposed logging interface
all have similar needs. We've been handling this on a per-instance
basis so far, but there's a greater need to address 'startup problems'
in a common/generic way.
* The "Register app/object/model with system-wide index" problem - we
have many different implementations of this pattern in Django already;
if we're going to add another one, it would be good to find a way to
abstract this into a common codebase, rather than reinventing the
wheel each time.
In addition to these two, there is also a nebulous "enterprise
settings support" issue out there. This essentially amounts to a need
to separate application settings from deployment settings. Having a
non-settings-based way to handle application registrations is
certainly a start down this path.
I know time is running short for you to get your proposal in, but I'd
be interested to see any ideas you have you on how your project could
lead to (or contribute to) solutions (or partial solutions) to these
problems.
> Timeline
> ---------
>
> 1) Implement the ``Application`` class. -- 2 weeks
> 2) Move ``django.db.models.loading`` to ``django.core.apps`` and refactor
> ``get_app``, ``get_model``, etc. -- 1 week
> 3) Modify the admin, management, translation, templatetags, templateloaders
> to use ``app.path`` -- 1 week
> 4) Testing and documentation -- 3 weeks
> 5) Bug fixes and backwards incompatibility problems -- 1 week
> 6) Time permitting possibly tackle the multiple instances of the same app
> problem. (about 2 weeks).
A few comments:
Your estimate for point 2 seems light, especially if taken in light of
the bigger issues of 'startup tasks' and 'registration as a pattern'
problems I mentioned earlier.
Elaboration of point 3 would be nice. What sort of modifications are required?
Point 4 sends up a red flag for me. Testing in particular isn't an
afterthought - it's an integral part of development. If the work of
step (1) doesn't include tests, it's incomplete as designed, IMHO.
Point 6 Ain't Gonna Happen (tm). Let me tell you right now that it's
more than 2 weeks work. The foreign key problem alone will require you
to jump all sorts of technical hurdles. You'd be better served
dropping this from your proposal altogether and concentrate on other
issues.
I also note that this timeline only adds up to 10 weeks. I'm going to
guess that you're allowing for UWA's exam break -- which is fine --
but if this is the case, you need to acknowledge it in your schedule.
> Any feedback would be greatly appreciated, sorry for the late application and
> good luck to all the other applicants :)
On a style issue - your proposal spends a lot of time explaining the
traditional "App() in INSTALLED_APPS" approach, which you then reject
for various (valid) reasons, and then moves into the interesting/novel
part. There's been plenty written on the App() approach; you would be
better served to not mention this at all if it doesn't form part of
what you intend to implement.
2c of advice - There are essentially two major subproblems here:
1) How to define an App. This bit isn't really controversial - it
needs to be a class of some sort. However, describing exactly what
this class can do and how it interacts with existing _meta structures
is important. Your current proposal covers this, but confuses the
issue with the old App() in INSTALLED_APPS notation.
2) How to register an App. This is the big beast that isn't
completely solved yet. You've presented a novel approach, but it's
important that you acknowledge in your proposal that this isn't a
solve issue yet, and will require additional work.
You would be well advised to acknowledge this split in your proposal.
Yours,
Russ Magee %-)
Nick Sandford
An App Loading mechanism for Django
====================================
About Me
----------
Hi everyone,
My name is Nick Sandford, I'm an electrical engineering student at the
University of Western Australia.
Background
-----------
I haven't been a particularly active contributor to any open source project -
here is where I hope to change that. In my current work at Christ Church
Grammar School we use Django heavily for most of our internal projects. I've
followed django-dev closely for a couple of years and I have poked around with
its internals on various occasions.
Plan
-----
Implement an improved application loading mechanism into Django.
Rationale
---------
Django current application loading code is inflexible in many cases. There
exists a need for a number of extra features to be added to the way
applications are handled such as:
* The ability to internationalise application names.
* The ability to customise application names similar to ``verbose_name`` in
``model._meta``
* Deploy the same application multiple times in a single project.
* Deploy two different applications with the same name.
* Manage settings within applications.
Method
-------
I don't intend to solve the third dot point of the previous list - it seems
like a difficult problem, possibly to be tackled post-GSoC. What I do intend
to do is to move towards 'application classes' more akin to
``django.contrib.admin``.
I plan to introduce a new file into the project structure - ``apps.py`` which
will be used to register installed applications with the ``AppCache``. I will
also move to introduce a new setting in ``settings.py``, ``APP_LOADER`` which
will be a string containing a dotted path to an application loading class. This
will serve to facilitate a move from ``settings.INSTALLED_APPS`` to the new
``apps.py``. ``APP_LOADER`` will take one of two values:
'django.core.apps.loader.legacy', which will use ``settings.INSTALLED_APPS`` or
'django.core.apps.loader.registry', which would use the new registry-based
approach. Only applications registered in ``apps.py`` in the project directory
will be registered with the ``AppCache``. The default APP_LOADER setting for
1.3 will be 'django.core.apps.loader.legacy'.
``apps.py`` will contain purely application-related setup. This should be handy
to manage application settings and to ensure ``settings.py`` doesn't get too
full of application-specific settings. This will allow us to register an app
in one of three ways something like:
.. sourcecode:: python
from django.core import apps
from blog import BlogApplication
class MyBlogApplication(BlogApplication):
api_key = 'testing'
another_blog = BlogApplication(label='blog2',
verbose_name=_('Another blog'),
api_key='anothertest')
# an application class.
apps.register(MyBlogApplication, label='blog', verbose_name=_('My blog'))
# an application instance.
apps.register(another_blog)
# old-style application.
apps.register('django.contrib.auth')
This could allow us not to touch ``settings.INSTALLED_APPS`` at all. If people
need to iterate over ``settings.INSTALLED_APPS``, a move to ``get_apps`` will
be recommended.
The ``Application`` class will be very similar to ``django.contrib.admin``'s
``AdminSite`` and will hopefully simplify application settings. If you write
views and urls directly on the ``Application`` class itself, instead of an
``from django.conf import settings`` and subsequent ``settings.API_KEY``, you
could just reference ``self.api_key`` for instance. This wouldn't be the
required, just an optional extra.
In addition to providing application settings an ``Application`` will be
required to explicitly define their models. These models could live outside
the traditional application structure, provided they are included in the
``models`` list on ``Application``. The current structure promotes strictly
requiring models for an application to reside in that application's
``models.py``. I wouldn't be promoting changing the current status quo with
regard to this, but it would be possible to deviate from it and include models
defined outside of the applications ``models.py`` on an ``Application``.
An application class would have other benefits, as evidenced by a short look at
``django.contrib.admin.AdminSite``. It could concievably be used to define a
set of 'base' add/edit/delete views for each model on an ``Application``. It
could even be used to set up an application's urls. This could make an
``Application`` class unwieldy and large however, so it won't be forced and
people can continue using views.py and urls.py as before.
Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.
There are a number of places within Django that rely on ``app_label`` and
that will need to be addressed. Ticket #3591 has patches that at least outline
areas that need changing, and the InstalledAppRevision wiki page is also quite
helpful. A non-exhaustive list of areas that need changing are: admin app
display name, admin permissions prefix, db table creation prefix, fixture
loading code, ``Model.Meta.app_label``, ``RelatedObject`` cross-app
identification, ``contrib.contenttypes``. There are also a number of places
that use string paths from ``settings.INSTALLED_APPS`` that should be simple to
change over.
I agree with moving ``django.db.models.loading`` to ``core.apps``, since we'll
no longer require applications to have a ``models.py``. A reference to the
new functions in ``core.apps`` will still live in ``django.db.models.loading``
for backwards compatibility.
A subclass of ``Application`` might look like:
.. sourcecode:: python
from django.views.simple import direct_to_template
from djang.core.apps import Application
from blog.models import Entry, Category
class BlogApplication(Application):
models = [Entry, Category]
api_key = 'default'
def entry_detail(self, slug, request, template='blog/entry_detail.html'):
entry = get_object_or_404(Entry, slug=slug)
context = {
'entry': entry,
'api_key': self.api_key,
}
return direct_to_template(request, template, context)
Hurdles
--------
There are a list of possible technical issues:
* Two applications with the same label.
* Registration of an app.
* Better handling of 'startup tasks'
* Worrying amounts of things that may affect backwards compatibility would
probably need addressing.
Solutions
----------
To solve the 'two applications named auth' problem, the ``AppCache`` keeps
track of application instances, not ``app_label``. For the case of two
applications with the same name, ``get_app`` should return a tuple containing
both application instances with that name. To ensure a single application
instance is returned with ``get_app``, another argument - ``path`` should be
added. ``get_models`` and ``get_model`` would take an application instance
and return models on that instance. This might affect the admin's handling of
applications.
Registration of an application is mentioned above, but it isn't a solved
problem and it needs work. With a deadline looming, all I can do is assure you
that I am committed to solving the problem as generically as possible. This
could pave the way for admin/signal/logging etc registration to become simpler.
Better handling of startup tasks would be investigated and addressed if
possible during the refactoring of ``AppCache`` and its associated functions.
Timeline
---------
1) Implement the ``Application`` class. -- 2 weeks
2) Move ``django.db.models.loading`` to ``django.core.apps`` and refactor
``get_app``, ``get_model``, etc. -- 3 weeks
3) Modify the admin, management, translation, templatetags, templateloaders
to use ``app.path`` -- 2 weeks
4) Testing and documentation -- 3 weeks
5) Bug fixes and backwards incompatibility problems -- 1 week
I have exams early June, so my availablity during that time will be minimal.
I apologise for lumping "Testing and documentation" together, but if I didn't
include them like that, someone might question if there is any of it going on
at all. Any feedback would be greatly appreciated, sorry for the late
application and good luck to all the other applicants :)
Thanks,
Nick
Nick Sandford
That was the initial idea, yes.
> * Is this something that needs to be handled as a
> "APP_LOADER='django.core.apps.loader.legacy'" which uses
> INSTALLED_APPS, and
> "APP_LOADER='django.core.apps.loader.registration'" which uses the new
> approach (i.e., that new projects won't need an INSTALLED_APPS
> setting)?
I quite like this approach, so I've incorporated it into the proposal.
Thanks! This makes it a kind-of all or nothing approach, you either
have settings.INSTALLED_APPS or you have the registration method.
Definitely simplfies trying to keep INSTALLED_APPS and the AppCache in
sync. The legacy loader can still be 'Application'-aware and you can
still iterate over INSTALLED_APPS.
Some of these are described in the updated proposal, not an in-depth
look but at least acknowledging the modifications that are required.
>
> Point 4 sends up a red flag for me. Testing in particular isn't an
> afterthought - it's an integral part of development. If the work of
> step (1) doesn't include tests, it's incomplete as designed, IMHO.
I figured if i didn't explicitly SAY that there would be testing and
documentation, then the comment would have been more akin to "where's
the time set aside for testing and documentation?" But yes, I agree
testing and documentation are an integral part of the development
process.
>
> Point 6 Ain't Gonna Happen (tm). Let me tell you right now that it's
> more than 2 weeks work. The foreign key problem alone will require you
> to jump all sorts of technical hurdles. You'd be better served
> dropping this from your proposal altogether and concentrate on other
> issues.
>
Noted and dropped from my proposal :-).
> I also note that this timeline only adds up to 10 weeks. I'm going to
> guess that you're allowing for UWA's exam break -- which is fine --
> but if this is the case, you need to acknowledge it in your schedule.
>
Yeah, exams are in early June. I've added that to the timeline section
of my proposal.
>> Any feedback would be greatly appreciated, sorry for the late application and
>> good luck to all the other applicants :)
>
> On a style issue - your proposal spends a lot of time explaining the
> traditional "App() in INSTALLED_APPS" approach, which you then reject
> for various (valid) reasons, and then moves into the interesting/novel
> part. There's been plenty written on the App() approach; you would be
> better served to not mention this at all if it doesn't form part of
> what you intend to implement.
>
> 2c of advice - There are essentially two major subproblems here:
>
> 1) How to define an App. This bit isn't really controversial - it
> needs to be a class of some sort. However, describing exactly what
> this class can do and how it interacts with existing _meta structures
> is important. Your current proposal covers this, but confuses the
> issue with the old App() in INSTALLED_APPS notation.
>
> 2) How to register an App. This is the big beast that isn't
> completely solved yet. You've presented a novel approach, but it's
> important that you acknowledge in your proposal that this isn't a
> solve issue yet, and will require additional work.
>
> You would be well advised to acknowledge this split in your proposal.
Certainly. Now for some mario kart... and constant checking of gmail.
Cheers,
Nick
Russell Keith-Magee
From my perspective, this is starting to look reasonably solid. It's
certainly got a lot of design work still to go (and signoff from a
BDFL will be required), but it's certainly covering the bases.
> Timeline
> ---------
>
> 1) Implement the ``Application`` class. -- 2 weeks
> 2) Move ``django.db.models.loading`` to ``django.core.apps`` and refactor
> ``get_app``, ``get_model``, etc. -- 3 weeks
> 3) Modify the admin, management, translation, templatetags, templateloaders
> to use ``app.path`` -- 2 weeks
> 4) Testing and documentation -- 3 weeks
> 5) Bug fixes and backwards incompatibility problems -- 1 week
A rule of thumb that I go by in professional life is that if a
schedule allocates anything more than a week, you don't fully
understand the problem you're proposing to solve. This is backed up by
some simple math: a 20% slip in a 1 week estimate is a day, but a 20%
slip in a 4 week estimate is almost another whole week. It's fine for
you schedule to be a *little* vague, but given that you've only got 11
weeks to start with (less once you subtract exam allowances) you need
to make sure your estimates are fairly tight.
I would also note that despite the fact that your proposal discusses
loading/startup tasks as part of the problem, your schedule doesn't
include any specific allowance for developing such a framework. If
nothing else, this is one way to provide some granularity to your
timeline.
> I have exams early June, so my availablity during that time will be minimal.
For convenience - where does this fit in the overall schedule (i.e.,
how much will you have done before you disappear for exams)? Do you
anticipate that you have completed enough work for your mentor to
assess you at the midterm assessment around July 12?
> I apologise for lumping "Testing and documentation" together, but if I didn't
> include them like that, someone might question if there is any of it going on
> at all.
As I said last time, it's fine to leave documentation till the end,
but testing is another matter. If you're not testing your code as you
go, UR DOIN IT WRONG. A schedule that implies otherwise is equally
wrong.
If you feel the need to reinforce that you have thought about testing,
then put a comment at the end that says "all time estimates include
allowances for developing relevant tests".
Yours,
Russ Magee %-)
Vinay Sajip
> It's a great place to start, and gives a good idea about where to look for
> problems. I'm not sure about get_installed_app_paths, rather than modifying
> settings.INSTALLED_APPS to contain a tuple of strings pointing to all
> application paths. If we end up using get_installed_app_paths it would break
> all of those using for app in settings.INSTALLED_APPS in third party code.
You're right: get_installed_app_paths needs to be replaced with e.g.
get_installed_apps() to get the app instances, while INSTALLED_APPS
remains a list of path strings. That will avoid backward compatibility
problems with 3rd-party code.
> You've taken the route of assuming applications won't know their models
> until runtime, I've expected that people explicitly assign models to apps.
>
Not exactly, it was more a case of keeping the changes as small as
possible, at the time of the original patch. It's certainly better to
have models explicitly associated with apps - it would make some
things easier, especially in a multi-db setup.
Regards,
Vinay Sajip