Re: Must a Django Database Support Migrations?

2014-01-21 Thread Shai Berger 
Hi,

(quotations reordered a little)

On Wednesday 22 January 2014 14:48:25 Russell Keith-Magee wrote:
> On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre  wrote:
> > *Why Disable Migrations?*
> > 
> > 1) Not all projects need schema migrations or want Django to manage the
> > migrations. My primary project has Django working against a legacy
> > database and relies upon an external tool (and a DBA) to manage schema
> > changes in our environment. This workflow uses syncdb to create the tables
> > in to a temporary database and then compares it will an external tool that
> > generates an SQL diff. This diff is tested by the DBA before being applied
> > to the production database. This basic workflow will continue even after
> > upgrading to Django 1.7.
> > 
> > This scenario does not necessarily need to be handled as a database
> > feature. Russell's idea during the IRC discussion was a database
> > configuration that acts as a safety to prevent migrations from being 
> > applied; similar to managed models.
> 
> I have no problem with this use case. My problem with the specific proposal
> in #21841 is that the database backend is the wrong place to be making this
> distinction. The decision as to whether the backend supports migrations is
> independent of whether the user wants to use them. The PostgreSQL supports
> migrations; that doesn't mean I want to use them.
> 
> If model-level Meta.managed isn't enough to disable migrations, then a
> settings.DATABASES flag may be called for, but that's different to what was
> originally proposed.
> 

I was going to say that the argument confuses the backend level with the 
project level. Russell beat me to it :)

> > 2) NoSQL databases don't necessarily have an enforced schema. What would
> > migration mean for NoSQL? Would it noop or attempt to update existing
> > data? Do we even care because NoSQL is not officially supported by Django?
> 
> This is a problem that we don't have (since we don't support NoSQL), so the
> question is completely hypothetical. However, I don't have any difficulty
> believing that the *concept* of migrations could exist on NoSQL databases -
> the implementation just won't look anything like "ALTER TABLE ADD COLUMN".
> 

+1 Russell, again.

> This means we're really only left with:
> > 3) The database backend or driver doesn't support altering the schema in a
> > way that would work with Django's schema migrations API. I can't think of
> > any that would be used with Django, but people still use mysql despite its
> > many faults, so anything is possible.
> 
> This one, which seems unlikely.

Actually, SQLite "doesn't support altering the schema in a way that would work 
with Django's schema migrations API". The SQLite backend bends over backwards 
to comply; its implementation of "alter column" is "recreate the table, 
copying the data". AFAIK it doesn't quite get everything right, even with the 
somersaults it pulls; and yet, it's close enough for comfort.

So, in order to really count as "can't support", a backend needs to be 
crippled to a level where implementing django-1.6-syncdb is probably 
impossible as well.

> 
> There's also option 4: The developer of a particular backend doesn't have
> the time or inclination to add support for migrations.
> 

which brings me back to

> > Database backend compliance is defined by its ability to pass Django's
> > test suite. A fully compliant database can pass 100% of tests dealing with
> > the database. If a database backend raises NotImplementedError for
> > schema_editor, it is currently 0% compliant because it cannot create the
> > database tables.
> > 
> > If database backends are not required to support migrations, then there
> > would need to be some form of fallback behavior to provide a Django 1.6
> > syncdb-esque behavior. It would create the schema without attempting
> > alterations.
> > 

and

> > *Potential Issues With Optional Support*
> > 
> > 2) Currently unknown level of effort or complexity to allow the migrations
> > to fallback to a Django 1.6 syncdb-esque behavior.

An alternative, which I think will have much lower costs, and send the right 
message about such backends is:

A) Django only changes the schema through migrations; if you don't want 
migrations in your backend or your project, than the schema changes need to 
happen some other way, using an external tool.

B) Allow the test suite to run on an existing schema. The Oracle backend 
already does this (badly) -- its six specific TEST_* parameters are awkwardly 
named, but allow you to say exactly which schema to use for testing, and 
whether or not you want it created. If this is made more general, then testing 
can be made to not depend on migrations;  with no migrations, you will need to 
take care of the test database yourself -- just like you take care of the 
production database.

For Django's own test-suite, tests which need migrations can even be 
automatically skipped if getting a

Re: Must a Django Database Support Migrations?

2014-01-21 Thread Russell Keith-Magee 
On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre  wrote:

> *Must a Django Database Support Migrations?*
>
> Django 1.7 adds schema migration support and this behavior is currently
> required
> to be able to effectively use Django and run the test suite. I opened
> ticket
> #21841 [1], which requests adding a DatabaseFeature to disable schema
> migrations. This ticket prompted an IRC discussion between Russell and
> myself
> that ended with the question, must a database backend support schema
> migrations
> to be compliant with Django 1.7? We're hoping to get opinions from others
> about
> this to figure out how to proceed.
>

I'm weighing in here to give my side of the argument :-)


> Database backend compliance is defined by its ability to pass Django's test
> suite. A fully compliant database can pass 100% of tests dealing with the
> database. If a database backend raises NotImplementedError for
> schema_editor, it
> is currently 0% compliant because it cannot create the database tables.
>
> If database backends are not required to support migrations, then there
> would
> need to be some form of fallback behavior to provide a Django 1.6
> syncdb-esque
> behavior. It would create the schema without attempting alterations.
>
> *Why Disable Migrations?*
>
> 1) Not all projects need schema migrations or want Django to manage the
> migrations. My primary project has Django working against a legacy
> database and
> relies upon an external tool (and a DBA) to manage schema changes in our
> environment. This workflow uses syncdb to create the tables in to a
> temporary
> database and then compares it will an external tool that generates an SQL
> diff.
> This diff is tested by the DBA before being applied to the production
> database.
> This basic workflow will continue even after upgrading to Django 1.7.
>
> This scenario does not necessarily need to be handled as a database
> feature.
> Russell's idea during the IRC discussion was a database configuration that
> acts
> as a safety to prevent migrations from being applied; similar to managed
> models.
>

I have no problem with this use case. My problem with the specific proposal
in #21841 is that the database backend is the wrong place to be making this
distinction. The decision as to whether the backend supports migrations is
independent of whether the user wants to use them. The PostgreSQL supports
migrations; that doesn't mean I want to use them.

If model-level Meta.managed isn't enough to disable migrations, then a
settings.DATABASES flag may be called for, but that's different to what was
originally proposed.


> 2) NoSQL databases don't necessarily have an enforced schema. What would
> migration mean for NoSQL? Would it noop or attempt to update existing
> data? Do
> we even care because NoSQL is not officially supported by Django?
>

This is a problem that we don't have (since we don't support NoSQL), so the
question is completely hypothetical. However, I don't have any difficulty
believing that the *concept* of migrations could exist on NoSQL databases -
the implementation just won't look anything like "ALTER TABLE ADD COLUMN".

This means we're really only left with:


> 3) The database backend or driver doesn't support altering the schema in a
> way
> that would work with Django's schema migrations API. I can't think of any
> that
> would be used with Django, but people still use mysql despite its many
> faults,
> so anything is possible.
>

This one, which seems unlikely. SQL is a pretty fungible standard, and yet
we've been able to coerce SQLite, MySQL, PostgreSQL and Oracle into the
task. From what I *do* know about the migrations implementation, it's
largely driven by high level primitives -- add a column, remove a column,
alter a column etc. These high level primitives don't enforce anything
significant on the underlying SQL -- and if it does, I'd argue that's a bug
in the abstraction.

There's also option 4: The developer of a particular backend doesn't have
the time or inclination to add support for migrations.


> *Potential Issues With Optional Support*
>
> 1) If migration support is optional, a concern was raised that backends
> that
> don't support it would give users a lesser experience and potentially make
> Django look bad.
>
> While this might be possible, the same concern holds true for any existing
> database backend that is buggy, doesn't fully implement the existing API,
> or the
> underlying database itself is slow or lacks basic functionality (e.g.
> referential integrity, ACID compliance, etc).
>

This is true, but at that point we can point at the database and say "it's
not our fault". MySQL *does* do dumb things with indexes (and subqueries,
and referential integrity, and.… :-) Oracle *is* slow to do certain table
setup operations. That's not our fault, and we can assign blame/point out
limitations as appropriate.

If we explicitly add APIs that allow people to say "I've got a Django 1.7
compliant database

Must a Django Database Support Migrations?

2014-01-21 Thread Michael Manfre 
*Must a Django Database Support Migrations?*

Django 1.7 adds schema migration support and this behavior is currently
required
to be able to effectively use Django and run the test suite. I opened ticket
#21841 [1], which requests adding a DatabaseFeature to disable schema
migrations. This ticket prompted an IRC discussion between Russell and
myself
that ended with the question, must a database backend support schema
migrations
to be compliant with Django 1.7? We're hoping to get opinions from others
about
this to figure out how to proceed.

Database backend compliance is defined by its ability to pass Django's test
suite. A fully compliant database can pass 100% of tests dealing with the
database. If a database backend raises NotImplementedError for
schema_editor, it
is currently 0% compliant because it cannot create the database tables.

If database backends are not required to support migrations, then there
would
need to be some form of fallback behavior to provide a Django 1.6
syncdb-esque
behavior. It would create the schema without attempting alterations.

*Why Disable Migrations?*

1) Not all projects need schema migrations or want Django to manage the
migrations. My primary project has Django working against a legacy database
and
relies upon an external tool (and a DBA) to manage schema changes in our
environment. This workflow uses syncdb to create the tables in to a
temporary
database and then compares it will an external tool that generates an SQL
diff.
This diff is tested by the DBA before being applied to the production
database.
This basic workflow will continue even after upgrading to Django 1.7.

This scenario does not necessarily need to be handled as a database feature.
Russell's idea during the IRC discussion was a database configuration that
acts
as a safety to prevent migrations from being applied; similar to managed
models.

2) NoSQL databases don't necessarily have an enforced schema. What would
migration mean for NoSQL? Would it noop or attempt to update existing data?
Do
we even care because NoSQL is not officially supported by Django?

3) The database backend or driver doesn't support altering the schema in a
way
that would work with Django's schema migrations API. I can't think of any
that
would be used with Django, but people still use mysql despite its many
faults,
so anything is possible.

*Potential Issues With Optional Support*

1) If migration support is optional, a concern was raised that backends that
don't support it would give users a lesser experience and potentially make
Django look bad.

While this might be possible, the same concern holds true for any existing
database backend that is buggy, doesn't fully implement the existing API,
or the
underlying database itself is slow or lacks basic functionality (e.g.
referential integrity, ACID compliance, etc).

2) Currently unknown level of effort or complexity to allow the migrations
to fallback to a Django 1.6 syncdb-esque behavior.

*Feedback*

Please share your questions and comments on the mailing list.


Regards,
Michael Manfre

[1] https://code.djangoproject.com/ticket/21841

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBt13g_X6W5SLWVBvQGrSdu7o7D8Oh2HzUercJQe4_6RwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Enforce the use of a unicode string in settings.LANGUAGES

2014-01-21 Thread gilberto dos santos alves 
please see that it is python directive not django. for all sources it is a
good practive for all we that use pt-br utf-8 explicit this on second line
of file python code

# -*- coding: utf-8 -*-

regards!




2014/1/21 Henrique Romano 

> Hi,
>
> As per the documentation[1], it is not clear that you _must_ use a unicode
> string for the language name.  If you don't use an unicode string, the
> following can happen:
>
> >>> from django.utils.translation import ugettext
> >>> ugettext("Português")
> Traceback (most recent call last):
> ...
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
> ordinal not in range(128)
>
> As opposed to:
>
> >>> ugettext(u"Português")
> u'Portugu\xeas'
>
> I was just having an issue where the languages available was being
> rendered in the template, but since TEMPLATE_DEBUG was enabled, no errors
> was generated in the development environment.  Switching TEMPLATE_DEBUG off
> in the production resulted in an exception with almost no clue on what
> happened.
>
> What do you guys think about making it clear that the user should always
> use an unicode string for the LANGUAGES setting?
>
> [1] https://docs.djangoproject.com/en/dev/ref/settings/#languages
> --
> Henrique Romano
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BEHudKfPXxry6T2tW_6ZNFzJgAJUHs3nO_mLkdp3Xk2wS09xg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAP9G-NLKRTiyM_P-1aMR2dKZh%3DgNU_0s6GYGoXLO%2BjmzZYnsCw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-21 Thread Russell Keith-Magee 
On Wed, Jan 22, 2014 at 2:03 AM, Carl Meyer  wrote:

> On 01/21/2014 06:48 AM, Russell Keith-Magee wrote:
> > As Marc indicated in his post, I don't think we should be treating this
> > as a permanent feature of the API, but as but as a migration aid. Yes,
> > default_app_config will exist as a bad smell for 2 releases, but come
> > Django 1.9, we can remove it - and/or we can raise a hard
> > InvalidConfiguration exception.
>
> I've re-read Marc's post, and I still don't understand _why_
> default_app_config is a bad smell, or why it should be deprecated so
> eagerly. There have been a lot of assertions made that it is bad, but I
> have seen very little by way of explanation of exactly what makes it bad.
>
> I think it's an entirely reasonable and explicit convenience feature of
> the API, in the long-term. For the majority of cases, users will want to
> use the default AppConfig defined by the app author: what is the
> concrete benefit of making them always type 'myapp.apps.AppConfig' into
> INSTALLED_APPS when we could have a simple and explicit protocol in
> place (documentable in no more than two sentences) that allows them to
> use 'myapp' instead for the common case?
>
> To me, rapid deprecation of default_app_config smells of forced churn
> for the sake of conceptual purity without real benefit. I think it will
> be much more confusing to users to get immediate deprecation warnings
> about a new feature than it would be to continue allowing either 'myapp'
> or 'myapp.apps.AppConfig' (presuming the app author has set
> default_app_config).
>
> At the moment, everyone's assertions about what default_app_config will
> or won't do is based on speculation. If we add it with immediate
> deprecation, we are forcing our hand in advance, without having any
> actual data from experience. Why not add it for one release without
> deprecation, so we can find out whether it is actually problematic in
> practice? Then we still have the option of deprecating it if it is a
> problem, but we haven't forced ourselves into a corner.
>

For my part, it's a light smell, in that it's a configuration variable
that's in a place you wouldn't historically expect to find a configuration
variable, for the purpose of defining a string substitution, which makes it
mildly implicit behavior. Based on explicit > implicit, I'd rather see
users actually type what they want to get (an AppConfig).

That said, I also agree with what you've said here. There's merit in
keeping the user experience simple and consistent with the existing usage,
and rapid deprecation churn does concern me a little. I'm happy to support
making default_app_config an immediately depreacted migration aid if it
makes the medicine more palatable to those opposed to it, but I'd be just
as happy if we kept it as a permanent API (or at least punt the decision to
a later release).

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84944SXY1nvp2RNBzCS-WGpyBcMeNAcsZofoaPw5xf_B%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Enforce the use of a unicode string in settings.LANGUAGES

2014-01-21 Thread Henrique Romano 
Hi,

As per the documentation[1], it is not clear that you _must_ use a unicode
string for the language name.  If you don't use an unicode string, the
following can happen:

>>> from django.utils.translation import ugettext
>>> ugettext("Português")
Traceback (most recent call last):
...
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
ordinal not in range(128)

As opposed to:

>>> ugettext(u"Português")
u'Portugu\xeas'

I was just having an issue where the languages available was being rendered
in the template, but since TEMPLATE_DEBUG was enabled, no errors was
generated in the development environment.  Switching TEMPLATE_DEBUG off in
the production resulted in an exception with almost no clue on what
happened.

What do you guys think about making it clear that the user should always
use an unicode string for the LANGUAGES setting?

[1] https://docs.djangoproject.com/en/dev/ref/settings/#languages
-- 
Henrique Romano

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BEHudKfPXxry6T2tW_6ZNFzJgAJUHs3nO_mLkdp3Xk2wS09xg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-21 Thread Shai Berger 
On Tuesday 21 January 2014 20:03:25 Carl Meyer wrote:
> On 01/21/2014 06:48 AM, Russell Keith-Magee wrote:
> > As Marc indicated in his post, I don't think we should be treating this
> > as a permanent feature of the API, but as but as a migration aid. Yes,
> > default_app_config will exist as a bad smell for 2 releases, but come
> > Django 1.9, we can remove it - and/or we can raise a hard
> > InvalidConfiguration exception.
> 
> I've re-read Marc's post, and I still don't understand _why_
> default_app_config is a bad smell, or why it should be deprecated so
> eagerly. There have been a lot of assertions made that it is bad, but I
> have seen very little by way of explanation of exactly what makes it bad.
> 
> I think it's an entirely reasonable and explicit convenience feature of
> the API, in the long-term. For the majority of cases, users will want to
> use the default AppConfig defined by the app author: what is the
> concrete benefit of making them always type 'myapp.apps.AppConfig' into
> INSTALLED_APPS when we could have a simple and explicit protocol in
> place (documentable in no more than two sentences) that allows them to
> use 'myapp' instead for the common case?
> 
+1 (actually, +1 for most everything Carl said in this discussion).

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201401212133.04375.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket #21751 review requested

2014-01-21 Thread Michael Manfre 
I agree with Aymeric in that cursors are very much like files. Wrapping a
single line of code in a with (or a try-finally) is a standard pattern and
allows Django to follow PEP 249 without extra modifications.

The overall feedback I've gotten from my pull request seems positive. I'll
rebase it against master and submit it for merging.

Regards,
Michael Manfre

On Sun, Jan 19, 2014 at 1:36 PM, Shai Berger  wrote:

> On Sunday 19 January 2014 10:44:32 Michael Manfre wrote:
> > On Sun, Jan 19, 2014 at 5:23 AM, Shai Berger  wrote:
> > > Still, spreading with-blocks all over the code for this looks very
> ugly to
> > > me.
> > > I'd rather add an execute_single() or execute_and_close() method to the
> > > cursors instead. Perhaps even only as private API, as that usage is
> mostly
> > > common within Django's code.
> >
> > You would rather deviate from PEP 249 to avoid requiring the users of a
> > cursor to explicitly close it?
>
> No. I'd rather extend the interface defined by PEP 249 in order to reduce
> the
> amount of RY in the code. Your PR has at least 10 instances of
>
> with connection.cursor() as cursor:
> cursor.execute(...)
> # block ends here
>
> and I think around 10 more of variations on the theme
>
> with connection.cursor() as cursor:
> cursor.execute(...)
> do_something_with(cursor.fetchone())
>
> In similar, though less general fashion, I would add to
> tests/introspection/tests.py a simple module-level function:
>
> def get_table_description(*args):
> with connection.cursor as cursor:
> return
> connection.introspection.get_table_description(cursor, *args)
>
> There are many other instances in the PR where a cursor defined at the with
> statement is used for more than one database command; I see those as net
> improvement.
>
> (I must admit that my initial reaction was "colored" by your other PR[1],
> where these one-line-with-blocks seem to be a larger percentage of the
> with-
> blocks. Still).
>
> Shai.
>
> [1] https://github.com/django/django/pull/2143
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2404579.hcV3zBsRXv%40deblack
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvSXJ2JHPavmpsZLvneJ9qqR%3DqZg2TRkUY%2BoYbkgoxBUw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-21 Thread Carl Meyer 
On 01/21/2014 06:48 AM, Russell Keith-Magee wrote:
> As Marc indicated in his post, I don't think we should be treating this
> as a permanent feature of the API, but as but as a migration aid. Yes,
> default_app_config will exist as a bad smell for 2 releases, but come
> Django 1.9, we can remove it - and/or we can raise a hard
> InvalidConfiguration exception. 

I've re-read Marc's post, and I still don't understand _why_
default_app_config is a bad smell, or why it should be deprecated so
eagerly. There have been a lot of assertions made that it is bad, but I
have seen very little by way of explanation of exactly what makes it bad.

I think it's an entirely reasonable and explicit convenience feature of
the API, in the long-term. For the majority of cases, users will want to
use the default AppConfig defined by the app author: what is the
concrete benefit of making them always type 'myapp.apps.AppConfig' into
INSTALLED_APPS when we could have a simple and explicit protocol in
place (documentable in no more than two sentences) that allows them to
use 'myapp' instead for the common case?

To me, rapid deprecation of default_app_config smells of forced churn
for the sake of conceptual purity without real benefit. I think it will
be much more confusing to users to get immediate deprecation warnings
about a new feature than it would be to continue allowing either 'myapp'
or 'myapp.apps.AppConfig' (presuming the app author has set
default_app_config).

At the moment, everyone's assertions about what default_app_config will
or won't do is based on speculation. If we add it with immediate
deprecation, we are forcing our hand in advance, without having any
actual data from experience. Why not add it for one release without
deprecation, so we can find out whether it is actually problematic in
practice? Then we still have the option of deprecating it if it is a
problem, but we haven't forced ourselves into a corner.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/52DEB66D.9080502%40oddbird.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

2014-01-21 Thread Russell Keith-Magee 
On Mon, Jan 20, 2014 at 11:09 PM, Jannis Leidel  wrote:

> On 19.01.2014, at 08:56, Russell Keith-Magee 
> wrote:
>
> > Hi all,
> >
> > First off - this isn't critical for 1.7 alpha - I'm raising it now
> because I've been in this space for the last couple of days as a result of
> the working on the check framework. I suspect any changes stemming from
> this discussion can be landed in the beta period without major problems.
> >
> > Also - Aymeric - you've done a great job with this app loading work. I
> didn't get much of a chance to follow along as it was unfolding, but the
> resultant work has been a pleasure to work with.
> >
> > With one exception :-)
> >
> > We've now got AppConfig objects for each app (e.g., contrib.admin).
> Those AppConfig objects can have ready() methods that invoke startup logic.
> This is all great stuff that has been a long time coming.
> >
> > *But*
> >
> > From a backwards compatibility perspective, there seems to be a gap in
> the way AppConfig objects are instantiated.
> >
> > The gap is this - historical apps (and historical documentation) calls
> for admin to be put into INSTALLED_APPS using 'django.contrib.admin'.
> However, when you do this, you get the system default AppConfig, not
> something that is admin specific. In order to get the new AdminConfig, you
> need to update your INSTALLED_APPS to point at
> "django.contrib.admin.apps.AdminConfig".
> >
> > This is fine, but it limits the logic that we (as a project) can put
> into AdminConfig.ready(), because existing projects won't reference the new
> AdminConfig. So, cleanups like putting admin.autoregister and check
> framework registrations into the ready function can't be done, because
> existing projects won't automatically gain that functionality.
> >
> > So, we end up with a situation where we have a nifty new on-startup
> method, but we can't use it for any of our own on-startup app requirements,
> because we have no guarantees that it's going to be invoked.
> >
>
> Hi Russ, all,
>
> Thanks for raising this issue as it’s indeed an important one to discuss.
> I hoped we’d have time to let the community figure out some of the
> techniques to handle version compatibility to Django but alas I didn’t
> expect the checks framework to so thoroughly crash the party. Well done! :)
> I wish we would have had more time to take these points into account when
> we were discussing the various details back in December, but I guess as
> long as 1.7 isn’t out it’s not too late. I probably would have made the
> argument that the check system may be best placed in AppConfig classes
> (e.g. in AppConfig.check_* methods). But on the other hand that may have
> made the work on the app config classes even harder.
>

We aren't entirely locked out on this as an option -- at the moment, we
just have to register checks, and we could register a system level check
that does a poll of all the apps looking for AppConfigs, and calling check
on them. However, this is predicated on the relevant apps having an
AppConfig, and being able to guarantee that this AppConfig is actually in
use.


> For the record, the app config concept has a long history with different
> implementations and goals but always (AFAIR) tried to fix one thing: the
> side effects of the implicit Django app concept. This issue is just another
> example of that problem. It bubbles up in our compatibility strategy which
> is to still allow dotted app module paths in INSTALLED_APPS. We assumed
> users to upgrade to the dotted app config paths in INSTALLED_APPS on their
> own eventually if the app in question required it. In other words, we
> really left it to the app authors to decide when to ask their users to make
> the jump. Instead of a hard coded check we wanted to gently push the new
> APIs into the community — also to find concept holes.
>
> I now believe that we may have been too conservative since that strategy
> introduces a new level of uncertainty in the app API. I can see the user
> questions already: “Does the 3rd party app XYZ work on 1.7?” “Can I also
> install it on my legacy 1.6 project?” “How am I going to override some
> options without a AppConfig?” “What’s the best way to create cross version
> compatible apps?”


Agreed that this is a problem.


> > I've dug through the mailing lists discussions about app-loading, and I
> can't see anywhere that this was explicitly discussed, so I can't tell if
> this was done deliberately, or as a side effect of the circular import
> problems that Aymeric described.
> >
> > Assuming that this wasn't done for import-related reasons, I can see a
> couple of possible solutions:
> >
> > 1) Require updating INSTALLED_APPS as a migration step. This is
> something we can detect with a check migration command - we inspect all the
> strings in INSTALLED_APPS; if it isn't an AppConfig subclass, look to see
> if there is an apps module, and if so, suggest that an update may be
>