Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
On 10/7/2010 3:24 AM, Jyrki Pulliainen wrote: >> So -- my original analysis still stands -- albeit for slightly more >> > complex reasons. The issue here is that your code was previously in >> > error, and now we're a little more vigilant about reporting the >> > potential problem. > Now that you've explained the problem a bit more deeply I think I have > to agree with you that my software was faulty. And I so hoped that the > flaws of my software could be accounted either by the flaws in the > framework or by the flaws in the programming language itself ;) > > - Jyrki Don't we all, sometimes? regards Steve -- DjangoCon US 2010 September 7-9 http://djangocon.us/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
On Oct 6, 5:12 pm, Russell Keith-Magee wrote: > Hi Jyrki, > > My apologies for not responding -- your message ran off the bottom of my > inbox. No prob, thanks for the response! > I've had a look at your sample code; the problem is that you're > importing the app1 module in two different ways. As a result of a > quirk of Python's module importer, 'r12950.app1.models' and > 'app1.models' are different modules. You are importing modules as > "r12950.app1", but your INSTALLED_APPS lists "app1". This means that > app1.models is actually getting imported and registered twice, and > depending on exactly what you are doing and the order in which you do > it, some of those registrations may be incomplete or corrupted. > > Now, you may not have observed any effects of this corruption -- > simple "load model, write to database" operations should still be fine > -- but that doesn't change the fact that model startup hasn't been > completed successfully. > > If you change either your importing style, or your INSTALLED_APPS > entry, the problem will go away. The problem will also go away if you > move the admin registration out of models.py, and into admin.py > (Strictly, using admin.py just masks the problem, but moving to using > admin.py is good practice anyway). We actually used fully qualified module paths in our production environment, they just got accidentally left out from my example. Anyhow, the solution there was to swap stuff to admin.py, reorganize imports and move some parts of code to "dummy" modules to avoid circular imports. > So -- my original analysis still stands -- albeit for slightly more > complex reasons. The issue here is that your code was previously in > error, and now we're a little more vigilant about reporting the > potential problem. Now that you've explained the problem a bit more deeply I think I have to agree with you that my software was faulty. And I so hoped that the flaws of my software could be accounted either by the flaws in the framework or by the flaws in the programming language itself ;) - Jyrki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
Hi Jyrki, My apologies for not responding -- your message ran off the bottom of my inbox. I've had a look at your sample code; the problem is that you're importing the app1 module in two different ways. As a result of a quirk of Python's module importer, 'r12950.app1.models' and 'app1.models' are different modules. You are importing modules as "r12950.app1", but your INSTALLED_APPS lists "app1". This means that app1.models is actually getting imported and registered twice, and depending on exactly what you are doing and the order in which you do it, some of those registrations may be incomplete or corrupted. Now, you may not have observed any effects of this corruption -- simple "load model, write to database" operations should still be fine -- but that doesn't change the fact that model startup hasn't been completed successfully. If you change either your importing style, or your INSTALLED_APPS entry, the problem will go away. The problem will also go away if you move the admin registration out of models.py, and into admin.py (Strictly, using admin.py just masks the problem, but moving to using admin.py is good practice anyway). So -- my original analysis still stands -- albeit for slightly more complex reasons. The issue here is that your code was previously in error, and now we're a little more vigilant about reporting the potential problem. Yours, Russ Magee %-) On Wed, Oct 6, 2010 at 3:36 PM, Jyrki Pulliainen wrote: > Sorry for bump up, but anything to say about this? Should I create a > ticket about the problem? > > - Jyrki > > On Oct 1, 9:41 am, Jyrki Pulliainen wrote: >> On Oct 1, 3:30 am, Russell Keith-Magee >> wrote: >> > Not really -- I've tried to reproduce the 2 apps and three models you >> > describe, but I don't see any errors on 1.1.1 or 1.1.2. >> >> > I appreciate that you can't release your actual source code, but if >> > you can generate a minimal test app that reproduces the problem case, >> > that would be very helpful. >> >> > As I said on twitter, this general class of problem is something we've >> > seen before; however, in all the cases we've been able to identify so >> > far, it's turned out to be a legitimate error that Django was >> > historically (and erroneously) suppressing. Yes, 1.1.2 generates more >> > errors, but that's because 1.1.1 masked legitimate errors, not because >> > 1.1.2 is broken. >> >> > If you can provide a test case that demonstrates otherwise, we're >> > happy to investigate. >> >> I managed to create a simulation of the situation (I suggest hitting >> the download button or using git, it seems to give the correct >> directory structure, the gist is a bit fubar as it doesn't appreciate >> directories): >> >> http://gist.github.com/605838 >> >> Seems to work exactly like our system does: If the app is started >> via ./manage.py runserver it starts up fine and displays the 404. The >> admin works fine and I can edit the model C just fine there. However, >> if I try to run the runner.py provided in the root directory the >> 'foobar' newer gets printed and instead the app crashes to an import >> error. This is why I'm suspecting there's some difference with the >> order of importing stuff and manage.py seems to get the order right. >> >> If I checkout Django version pre-12950 both the admin and runner.py >> work just fine (as the ImportError gets swallowed). >> >> - Jyrki > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
Sorry for bump up, but anything to say about this? Should I create a ticket about the problem? - Jyrki On Oct 1, 9:41 am, Jyrki Pulliainen wrote: > On Oct 1, 3:30 am, Russell Keith-Magee > wrote: > > Not really -- I've tried to reproduce the 2 apps and three models you > > describe, but I don't see any errors on 1.1.1 or 1.1.2. > > > I appreciate that you can't release your actual source code, but if > > you can generate a minimal test app that reproduces the problem case, > > that would be very helpful. > > > As I said on twitter, this general class of problem is something we've > > seen before; however, in all the cases we've been able to identify so > > far, it's turned out to be a legitimate error that Django was > > historically (and erroneously) suppressing. Yes, 1.1.2 generates more > > errors, but that's because 1.1.1 masked legitimate errors, not because > > 1.1.2 is broken. > > > If you can provide a test case that demonstrates otherwise, we're > > happy to investigate. > > I managed to create a simulation of the situation (I suggest hitting > the download button or using git, it seems to give the correct > directory structure, the gist is a bit fubar as it doesn't appreciate > directories): > > http://gist.github.com/605838 > > Seems to work exactly like our system does: If the app is started > via ./manage.py runserver it starts up fine and displays the 404. The > admin works fine and I can edit the model C just fine there. However, > if I try to run the runner.py provided in the root directory the > 'foobar' newer gets printed and instead the app crashes to an import > error. This is why I'm suspecting there's some difference with the > order of importing stuff and manage.py seems to get the order right. > > If I checkout Django version pre-12950 both the admin and runner.py > work just fine (as the ImportError gets swallowed). > > - Jyrki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
On Oct 1, 3:30 am, Russell Keith-Magee wrote: > Not really -- I've tried to reproduce the 2 apps and three models you > describe, but I don't see any errors on 1.1.1 or 1.1.2. > > I appreciate that you can't release your actual source code, but if > you can generate a minimal test app that reproduces the problem case, > that would be very helpful. > > As I said on twitter, this general class of problem is something we've > seen before; however, in all the cases we've been able to identify so > far, it's turned out to be a legitimate error that Django was > historically (and erroneously) suppressing. Yes, 1.1.2 generates more > errors, but that's because 1.1.1 masked legitimate errors, not because > 1.1.2 is broken. > > If you can provide a test case that demonstrates otherwise, we're > happy to investigate. I managed to create a simulation of the situation (I suggest hitting the download button or using git, it seems to give the correct directory structure, the gist is a bit fubar as it doesn't appreciate directories): http://gist.github.com/605838 Seems to work exactly like our system does: If the app is started via ./manage.py runserver it starts up fine and displays the 404. The admin works fine and I can edit the model C just fine there. However, if I try to run the runner.py provided in the root directory the 'foobar' newer gets printed and instead the app crashes to an import error. This is why I'm suspecting there's some difference with the order of importing stuff and manage.py seems to get the order right. If I checkout Django version pre-12950 both the admin and runner.py work just fine (as the ImportError gets swallowed). - Jyrki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
On Thu, Sep 30, 2010 at 8:01 PM, Jyrki Pulliainen wrote: > Hi! > > We encountered a possible backwards incompatibility with change 12950 > [1]. This was noticed when upgrading from 1.1.1 to 1.1.2. > > If I understand correctly the change 12950 removes squelching of > ImportErrors from AppCache. AppCache in turn provides reverse- > relations for app introspection, for example in admin interface. This > change now causes the ImportError in one otherwise fine case to > propagate and break the application. > > Funnily enough, this does not break our application per se. The webapp > still continues to work with admin interface fully responsive, doing > all the changes wanted, tests passing etc. This only affects a smaller > worker script that is run via upstart. > > This upstart script imported a single model class (let's say, model > class A) from a single app. However, this models.py file also had > another model (class C) and it's admin definitions (there was actually > no change even if these were moved to separate admin.py, we have a > custom AdminSite object). For some reason importing this single caused > the import error to fire. And as said before this behavior doesn't > surface for example when running ./manage.py runserver, only trying to > start the worker script causes the ImportError. > > Unfortunately this software isn't open source, but I think I can > describe the module layout a bit though: > > Class A -- the "troublemaker" class has a reverse relationship with > class B from another app, ie. class B has ForeignKeyField to A. > Neither of these classes has any admin interface and they're not > registered to the admin site object > Class C -- another model in the same models.py (and app) as Class A. > This is registed to the AdminSite. > > Now, when the worker starts the importing of class A causes > ImportError due to the admin site trying to import stuff in AppCache, > even it is not needed. The models.py it is trying to import when > crashing is the models.py containing the Class B. > > Hopefully this description is even a bit helpful, even though it's a > hard to get the whole picture without the code. Not really -- I've tried to reproduce the 2 apps and three models you describe, but I don't see any errors on 1.1.1 or 1.1.2. I appreciate that you can't release your actual source code, but if you can generate a minimal test app that reproduces the problem case, that would be very helpful. As I said on twitter, this general class of problem is something we've seen before; however, in all the cases we've been able to identify so far, it's turned out to be a legitimate error that Django was historically (and erroneously) suppressing. Yes, 1.1.2 generates more errors, but that's because 1.1.1 masked legitimate errors, not because 1.1.2 is broken. If you can provide a test case that demonstrates otherwise, we're happy to investigate. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
On Sep 30, 3:38 pm, Karen Tracey wrote:
> On Thu, Sep 30, 2010 at 8:01 AM, Jyrki Pulliainen wrote:
> > We encountered a possible backwards incompatibility with change 12950
> > [1]. This was noticed when upgrading from 1.1.1 to 1.1.2.
>
> > If I understand correctly the change 12950 removes squelching of
> > ImportErrors from AppCache. AppCache in turn provides reverse-
> > relations for app introspection, for example in admin interface. This
> > change now causes the ImportError in one otherwise fine case to
> > propagate and break the application.
>
> > Funnily enough, this does not break our application per se. The webapp
> > still continues to work with admin interface fully responsive, doing
> > all the changes wanted, tests passing etc. This only affects a smaller
> > worker script that is run via upstart.
>
> [additional info skipped]
>
> Without specifics (at least a traceback from the error) it's virtually
> impossible to say whether the problem you encountered was a flaw in this
> changeset or an error in the application. The original fix here was updated
> based on user feedback, see for
> examplehttp://code.djangoproject.com/ticket/13335. There may also have been at
> least one other like that but I don't recall exactly and do not have time to
> search now. So far as I know the version of the change that appears in a
> released version only reports true application errors (e.g. circular
> imports) that really should never have been suppressed in the first place.
Traceback follows:
Traceback (most recent call last):
File "./bin/icm-init-worker", line 4, in
from inoi.management.central.node_manager.workers import
InitWorker
File "/home/jyrki/local/lib/python2.6/site-packages/inoi/management/
central/node_manager/workers.py", line 3, in
from .models import Node
File "/home/jyrki/local/lib/python2.6/site-packages/inoi/management/
central/node_manager/models.py", line 24, in
from inoi.management.central import admin
File "/home/jyrki/local/lib/python2.6/site-packages/inoi/management/
central/admin.py", line 34, in
site.register(Group)
File "/home/jyrki/local/lib/python2.6/site-packages/django/contrib/
admin/sites.py", line 90, in register
validate(admin_class, model)
File "/home/jyrki/local/lib/python2.6/site-packages/django/contrib/
admin/validation.py", line 22, in validate
models.get_apps()
File "/home/jyrki/local/lib/python2.6/site-packages/django/db/models/
loading.py", line 114, in get_apps
self._populate()
File "/home/jyrki/local/lib/python2.6/site-packages/django/db/models/
loading.py", line 63, in _populate
self.load_app(app_name)
File "/home/jyrki/local/lib/python2.6/site-packages/django/db/models/
loading.py", line 77, in load_app
models = import_module('.models', app_name)
File "/home/jyrki/local/lib/python2.6/site-packages/django/utils/
importlib.py", line 35, in import_module
__import__(name)
File "/home/jyrki/local/lib/python2.6/site-packages/inoi/management/
central/node_manager/firmware/models.py", line 5, in
from inoi.management.central.node_manager.models import (
ImportError: cannot import name Node
- Jyrki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
On Thu, Sep 30, 2010 at 8:01 AM, Jyrki Pulliainen wrote: > We encountered a possible backwards incompatibility with change 12950 > [1]. This was noticed when upgrading from 1.1.1 to 1.1.2. > > If I understand correctly the change 12950 removes squelching of > ImportErrors from AppCache. AppCache in turn provides reverse- > relations for app introspection, for example in admin interface. This > change now causes the ImportError in one otherwise fine case to > propagate and break the application. > > Funnily enough, this does not break our application per se. The webapp > still continues to work with admin interface fully responsive, doing > all the changes wanted, tests passing etc. This only affects a smaller > worker script that is run via upstart. > [additional info skipped] Without specifics (at least a traceback from the error) it's virtually impossible to say whether the problem you encountered was a flaw in this changeset or an error in the application. The original fix here was updated based on user feedback, see for example http://code.djangoproject.com/ticket/13335. There may also have been at least one other like that but I don't recall exactly and do not have time to search now. So far as I know the version of the change that appears in a released version only reports true application errors (e.g. circular imports) that really should never have been suppressed in the first place. Karen -- http://tracey.org/kmt/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Possible backwards incompatibility introduced by change 12950 (in upgrade from 1.1.1 to 1.1.2)
Hi! We encountered a possible backwards incompatibility with change 12950 [1]. This was noticed when upgrading from 1.1.1 to 1.1.2. If I understand correctly the change 12950 removes squelching of ImportErrors from AppCache. AppCache in turn provides reverse- relations for app introspection, for example in admin interface. This change now causes the ImportError in one otherwise fine case to propagate and break the application. Funnily enough, this does not break our application per se. The webapp still continues to work with admin interface fully responsive, doing all the changes wanted, tests passing etc. This only affects a smaller worker script that is run via upstart. This upstart script imported a single model class (let's say, model class A) from a single app. However, this models.py file also had another model (class C) and it's admin definitions (there was actually no change even if these were moved to separate admin.py, we have a custom AdminSite object). For some reason importing this single caused the import error to fire. And as said before this behavior doesn't surface for example when running ./manage.py runserver, only trying to start the worker script causes the ImportError. Unfortunately this software isn't open source, but I think I can describe the module layout a bit though: Class A -- the "troublemaker" class has a reverse relationship with class B from another app, ie. class B has ForeignKeyField to A. Neither of these classes has any admin interface and they're not registered to the admin site object Class C -- another model in the same models.py (and app) as Class A. This is registed to the AdminSite. Now, when the worker starts the importing of class A causes ImportError due to the admin site trying to import stuff in AppCache, even it is not needed. The models.py it is trying to import when crashing is the models.py containing the Class B. Hopefully this description is even a bit helpful, even though it's a hard to get the whole picture without the code. My 2 euro-cents here is that starting the server with runserver (or as fastcgi, we've tested that too) does the imports in correct order. It imports the applications and inserts them in sys.modules in orderly fashion without causing any illegal circular import Python can't handle. But when not using the normal startup procedure of manage.py runserver and instead just directly importing one of the models the admin site importing goes fubar and ends up in circular import. The old implementation just swallowed this importerror and let the worker to continue normally. This is the reason why I think this is a change that breaks backwards compatibility in this rare case. For the record, we fixed this, but it caused some extra complexity to our application as we had to split stuff in multiple dummy files for importing certain stuff that previously worked and we also needed to do some overhaul to the way we built our admin site. So everything is now working :) [1] http://code.djangoproject.com/changeset/12950 - Jyrki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django cron script works in django 1.1.1 but not in 1.1.2 and 1.2.1
On 6 Giu, 16:31, Karen Tracey wrote:
> On Sun, Jun 6, 2010 at 9:14 AM, drakkan wrote:
> > I'm migrating my sites to django 1.2.1 however I noticed my cron
> > scripts doesn't work anymore with the latest django version, I'm using
> > the setup_environ method
>
> >http://www.b-list.org/weblog/2007/sep/22/standalone-django-scripts/
>
> > and I tryed also the DJANGO_SETTINGS_MODULE environment variable
> > method with the same results:
>
> > 1) my cron script work fine in 1.1.1 but not in 1.1.2 and 1.2.1
> > 2) the script exit with a trace such this:
>
> > Traceback (most recent call last):
> > File "syncdomains.py", line 16, in
> > from systemcp.domini.models import Domain, ProtectedArea,
> > HttpErrors
> > File "/home/nicola/workspace/SystemPanel/src/systemcp/domini/
> > models.py", line 3, in
> > from systemcp.utenti.models import UserInfo
> > File "/home/nicola/workspace/SystemPanel/src/systemcp/utenti/
> > models.py", line 76, in
> > admin.site.register(UserInfo,UserInfoAdmin)
> > File "/usr/lib/python2.6/site-packages/django/contrib/admin/
> > sites.py", line 90, in register
> > validate(admin_class, model)
> > File "/usr/lib/python2.6/site-packages/django/contrib/admin/
> > validation.py", line 20, in validate
> > models.get_apps()
> > File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> > line 115, in get_apps
> > self._populate()
> > File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> > line 64, in _populate
> > self.load_app(app_name)
> > File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> > line 78, in load_app
> > models = import_module('.models', app_name)
> > File "/usr/lib/python2.6/site-packages/django/utils/importlib.py",
> > line 35, in import_module
> > __import__(name)
> > File "/home/nicola/workspace/SystemPanel/src/systemcp/ftp/
> > models.py", line 4, in
> > from systemcp.domini.models import Domain
> > ImportError: cannot import name Domain
>
> > this trace tipycally mean circolar import but I'm sure I don't have
> > this error in my code, maybe I have to change my envirornment
> > initialization for cron script since 1.1.2?
>
> > If I execute the same imports I do in my cron script using python
> > manage.py shell, they works fine so I think something changed in the
> > environment initialization
>
> > any hints?
>
> There is a circular import. The code is in the process of importing Domain
> and hits code where it again attempts to import Domain. The resulting
> ImportError was mistakenly suppressed in 1.1, this issue was reported in
> ticket #11696 (http://code.djangoproject.com/ticket/11696) and the fix for
> that has caused the problem to surface in your cron script.
>
> Now, the circular import is not directly in your app code. What's happening
> is your app code, in models.py, is registering models with the admin (line
> 76 of /home/nicola/workspace/
> SystemPanel/src/systemcp/utenti/models.py is attempting to register an admin
> module for UserInfo.When DEBUG is on, admin registrations trigger validation
> code that first loads all app models, and that is what is resulting in the
> circular import, because your cron script is already in the process of
> importing one of the models.
>
> One fix would be to remove the admin registrations from models.py: that's
> generally not a good place for them. Having them in models.py tends to lead
> to mysteriously missing models in the admin when you run on production
> server with debug off, since then models.py is not necessarily loaded before
> the admin code is called to process requests. Moving admin registrations to
> an admin.py file and calling admin.autodiscover() from urls.py is the
> currently best-practice way of ensuring admin registrations are done when
> they need to be...and it would avoid this circular import you are seeing in
> your cron script.
>
> Another way to fix it would be to turn of DEBUG when running the cron
> script. Then the admin validation code won't be called, which will avoid the
> circular import. But really, admin registrations should not be done in
> models.py.
>
> Karen
> --http://tracey.org/kmt/
Thanks Karen,
I moved all the admin registrations in a separate admin.py file and
now all is fine,
drakkan
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: django cron script works in django 1.1.1 but not in 1.1.2 and 1.2.1
On Sun, Jun 6, 2010 at 9:14 AM, drakkan wrote:
> I'm migrating my sites to django 1.2.1 however I noticed my cron
> scripts doesn't work anymore with the latest django version, I'm using
> the setup_environ method
>
> http://www.b-list.org/weblog/2007/sep/22/standalone-django-scripts/
>
> and I tryed also the DJANGO_SETTINGS_MODULE environment variable
> method with the same results:
>
> 1) my cron script work fine in 1.1.1 but not in 1.1.2 and 1.2.1
> 2) the script exit with a trace such this:
>
> Traceback (most recent call last):
> File "syncdomains.py", line 16, in
>from systemcp.domini.models import Domain, ProtectedArea,
> HttpErrors
> File "/home/nicola/workspace/SystemPanel/src/systemcp/domini/
> models.py", line 3, in
>from systemcp.utenti.models import UserInfo
> File "/home/nicola/workspace/SystemPanel/src/systemcp/utenti/
> models.py", line 76, in
>admin.site.register(UserInfo,UserInfoAdmin)
> File "/usr/lib/python2.6/site-packages/django/contrib/admin/
> sites.py", line 90, in register
>validate(admin_class, model)
> File "/usr/lib/python2.6/site-packages/django/contrib/admin/
> validation.py", line 20, in validate
>models.get_apps()
> File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> line 115, in get_apps
>self._populate()
> File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> line 64, in _populate
>self.load_app(app_name)
> File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> line 78, in load_app
>models = import_module('.models', app_name)
> File "/usr/lib/python2.6/site-packages/django/utils/importlib.py",
> line 35, in import_module
>__import__(name)
> File "/home/nicola/workspace/SystemPanel/src/systemcp/ftp/
> models.py", line 4, in
>from systemcp.domini.models import Domain
> ImportError: cannot import name Domain
>
> this trace tipycally mean circolar import but I'm sure I don't have
> this error in my code, maybe I have to change my envirornment
> initialization for cron script since 1.1.2?
>
> If I execute the same imports I do in my cron script using python
> manage.py shell, they works fine so I think something changed in the
> environment initialization
>
> any hints?
>
There is a circular import. The code is in the process of importing Domain
and hits code where it again attempts to import Domain. The resulting
ImportError was mistakenly suppressed in 1.1, this issue was reported in
ticket #11696 (http://code.djangoproject.com/ticket/11696) and the fix for
that has caused the problem to surface in your cron script.
Now, the circular import is not directly in your app code. What's happening
is your app code, in models.py, is registering models with the admin (line
76 of /home/nicola/workspace/
SystemPanel/src/systemcp/utenti/models.py is attempting to register an admin
module for UserInfo.When DEBUG is on, admin registrations trigger validation
code that first loads all app models, and that is what is resulting in the
circular import, because your cron script is already in the process of
importing one of the models.
One fix would be to remove the admin registrations from models.py: that's
generally not a good place for them. Having them in models.py tends to lead
to mysteriously missing models in the admin when you run on production
server with debug off, since then models.py is not necessarily loaded before
the admin code is called to process requests. Moving admin registrations to
an admin.py file and calling admin.autodiscover() from urls.py is the
currently best-practice way of ensuring admin registrations are done when
they need to be...and it would avoid this circular import you are seeing in
your cron script.
Another way to fix it would be to turn of DEBUG when running the cron
script. Then the admin validation code won't be called, which will avoid the
circular import. But really, admin registrations should not be done in
models.py.
Karen
--
http://tracey.org/kmt/
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: django cron script works in django 1.1.1 but not in 1.1.2 and 1.2.1
with 1.2.0 beta 1 my cron script works too
On 6 Giu, 15:14, drakkan wrote:
> Hi,
>
> I'm migrating my sites to django 1.2.1 however I noticed my cron
> scripts doesn't work anymore with the latest django version, I'm using
> the setup_environ method
>
> http://www.b-list.org/weblog/2007/sep/22/standalone-django-scripts/
>
> and I tryed also the DJANGO_SETTINGS_MODULE environment variable
> method with the same results:
>
> 1) my cron script work fine in 1.1.1 but not in 1.1.2 and 1.2.1
> 2) the script exit with a trace such this:
>
> Traceback (most recent call last):
> File "syncdomains.py", line 16, in
> from systemcp.domini.models import Domain, ProtectedArea,
> HttpErrors
> File "/home/nicola/workspace/SystemPanel/src/systemcp/domini/
> models.py", line 3, in
> from systemcp.utenti.models import UserInfo
> File "/home/nicola/workspace/SystemPanel/src/systemcp/utenti/
> models.py", line 76, in
> admin.site.register(UserInfo,UserInfoAdmin)
> File "/usr/lib/python2.6/site-packages/django/contrib/admin/
> sites.py", line 90, in register
> validate(admin_class, model)
> File "/usr/lib/python2.6/site-packages/django/contrib/admin/
> validation.py", line 20, in validate
> models.get_apps()
> File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> line 115, in get_apps
> self._populate()
> File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> line 64, in _populate
> self.load_app(app_name)
> File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
> line 78, in load_app
> models = import_module('.models', app_name)
> File "/usr/lib/python2.6/site-packages/django/utils/importlib.py",
> line 35, in import_module
> __import__(name)
> File "/home/nicola/workspace/SystemPanel/src/systemcp/ftp/
> models.py", line 4, in
> from systemcp.domini.models import Domain
> ImportError: cannot import name Domain
>
> this trace tipycally mean circolar import but I'm sure I don't have
> this error in my code, maybe I have to change my envirornment
> initialization for cron script since 1.1.2?
>
> If I execute the same imports I do in my cron script using python
> manage.py shell, they works fine so I think something changed in the
> environment initialization
>
> any hints?
>
> thanks
> drakkan
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
django cron script works in django 1.1.1 but not in 1.1.2 and 1.2.1
Hi,
I'm migrating my sites to django 1.2.1 however I noticed my cron
scripts doesn't work anymore with the latest django version, I'm using
the setup_environ method
http://www.b-list.org/weblog/2007/sep/22/standalone-django-scripts/
and I tryed also the DJANGO_SETTINGS_MODULE environment variable
method with the same results:
1) my cron script work fine in 1.1.1 but not in 1.1.2 and 1.2.1
2) the script exit with a trace such this:
Traceback (most recent call last):
File "syncdomains.py", line 16, in
from systemcp.domini.models import Domain, ProtectedArea,
HttpErrors
File "/home/nicola/workspace/SystemPanel/src/systemcp/domini/
models.py", line 3, in
from systemcp.utenti.models import UserInfo
File "/home/nicola/workspace/SystemPanel/src/systemcp/utenti/
models.py", line 76, in
admin.site.register(UserInfo,UserInfoAdmin)
File "/usr/lib/python2.6/site-packages/django/contrib/admin/
sites.py", line 90, in register
validate(admin_class, model)
File "/usr/lib/python2.6/site-packages/django/contrib/admin/
validation.py", line 20, in validate
models.get_apps()
File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
line 115, in get_apps
self._populate()
File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
line 64, in _populate
self.load_app(app_name)
File "/usr/lib/python2.6/site-packages/django/db/models/loading.py",
line 78, in load_app
models = import_module('.models', app_name)
File "/usr/lib/python2.6/site-packages/django/utils/importlib.py",
line 35, in import_module
__import__(name)
File "/home/nicola/workspace/SystemPanel/src/systemcp/ftp/
models.py", line 4, in
from systemcp.domini.models import Domain
ImportError: cannot import name Domain
this trace tipycally mean circolar import but I'm sure I don't have
this error in my code, maybe I have to change my envirornment
initialization for cron script since 1.1.2?
If I execute the same imports I do in my cron script using python
manage.py shell, they works fine so I think something changed in the
environment initialization
any hints?
thanks
drakkan
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: ANN: Django 1.1.2 and Django 1.2 released
On May 18, 12:39 am, rahul jain wrote: > Awesome job...but I discovered just one problem. Select all missing from > admin panel. So now i cannot select all the objects if i want to from admin > panel. It was fine on django 1.1. Its not fine on django 1.2 nor in the > development versions. Works fine for me RJ -- you're talking about the list of objects for a given model, yes? Regards Scott -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: ANN: Django 1.1.2 and Django 1.2 released
Awesome job...but I discovered just one problem. Select all missing from admin panel. So now i cannot select all the objects if i want to from admin panel. It was fine on django 1.1. Its not fine on django 1.2 nor in the development versions. --RJ On Mon, May 17, 2010 at 7:11 PM, Joshua Partogi wrote: > I have just read through the release notes, and really amazed how > django 1.2 has evolved from 1.1. > > Kudos to everyone that is involved and put all effort into delivering > django 1.2 > > > Kind regards, > Joshua > > > On May 18, 9:46 am, Continuation wrote: > > Congrats to the Django team. > > > > Thanks for the great job. Really appreciate all your work. > > > > On May 17, 2:19 pm, James Bennett wrote: > > > > > > > > > We're pleased today to announce the release of both Django 1.1.2 -- > > > the second bugfix release in the 1.1 series -- and the long-awaited > > > Django 1.2. > > > > > More information is available over at djangoproject.com: > > > > > * Django 1.1.2 release announcement: > http://www.djangoproject.com/weblog/2010/may/17/112/ > > > * Django 1.1.2 release notes: > http://docs.djangoproject.com/en/1.1/releases/1.1.2/ > > > * Django 1.2 release announcement: > http://www.djangoproject.com/weblog/2010/may/17/12/ > > > * Django 1.2 release notes: > http://docs.djangoproject.com/en/dev/releases/1.2/ > > > > > -- > > > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Django users" group. > > > To post to this group, send email to django-us...@googlegroups.com. > > > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com > . > > > For more options, visit this group athttp:// > groups.google.com/group/django-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: ANN: Django 1.1.2 and Django 1.2 released
I have just read through the release notes, and really amazed how django 1.2 has evolved from 1.1. Kudos to everyone that is involved and put all effort into delivering django 1.2 Kind regards, Joshua On May 18, 9:46 am, Continuation wrote: > Congrats to the Django team. > > Thanks for the great job. Really appreciate all your work. > > On May 17, 2:19 pm, James Bennett wrote: > > > > > We're pleased today to announce the release of both Django 1.1.2 -- > > the second bugfix release in the 1.1 series -- and the long-awaited > > Django 1.2. > > > More information is available over at djangoproject.com: > > > * Django 1.1.2 release > > announcement:http://www.djangoproject.com/weblog/2010/may/17/112/ > > * Django 1.1.2 release > > notes:http://docs.djangoproject.com/en/1.1/releases/1.1.2/ > > * Django 1.2 release > > announcement:http://www.djangoproject.com/weblog/2010/may/17/12/ > > * Django 1.2 release > > notes:http://docs.djangoproject.com/en/dev/releases/1.2/ > > > -- > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > correct." > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: ANN: Django 1.1.2 and Django 1.2 released
Congrats to the Django team. Thanks for the great job. Really appreciate all your work. On May 17, 2:19 pm, James Bennett wrote: > We're pleased today to announce the release of both Django 1.1.2 -- > the second bugfix release in the 1.1 series -- and the long-awaited > Django 1.2. > > More information is available over at djangoproject.com: > > * Django 1.1.2 release > announcement:http://www.djangoproject.com/weblog/2010/may/17/112/ > * Django 1.1.2 release > notes:http://docs.djangoproject.com/en/1.1/releases/1.1.2/ > * Django 1.2 release > announcement:http://www.djangoproject.com/weblog/2010/may/17/12/ > * Django 1.2 release notes:http://docs.djangoproject.com/en/dev/releases/1.2/ > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
ANN: Django 1.1.2 and Django 1.2 released
We're pleased today to announce the release of both Django 1.1.2 -- the second bugfix release in the 1.1 series -- and the long-awaited Django 1.2. More information is available over at djangoproject.com: * Django 1.1.2 release announcement: http://www.djangoproject.com/weblog/2010/may/17/112/ * Django 1.1.2 release notes: http://docs.djangoproject.com/en/1.1/releases/1.1.2/ * Django 1.2 release announcement: http://www.djangoproject.com/weblog/2010/may/17/12/ * Django 1.2 release notes: http://docs.djangoproject.com/en/dev/releases/1.2/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.1.2?
2010/5/17 Russell Keith-Magee : > On Mon, May 17, 2010 at 6:56 PM, Antoni Aloy wrote: >> Hello, >> >> On the main Django page the official version is 1.1.1 but there is a >> new 1.1.2 version even documented if you make a search on the Django >> site. Is the 1.1.2 officialy supported? > > Unofficially, yes it is officially supported :-) > :-P In fact the 1.1.2 version is on Pypi http://pypi.python.org/pypi/Django my fear was that was a fake package until I have searched the documentation. Best regards, -- Antoni Aloy López Blog: http://trespams.com Site: http://apsl.net -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.1.2?
On Mon, May 17, 2010 at 6:56 PM, Antoni Aloy wrote: > Hello, > > On the main Django page the official version is 1.1.1 but there is a > new 1.1.2 version even documented if you make a search on the Django > site. Is the 1.1.2 officialy supported? Unofficially, yes it is officially supported :-) To clarify -- James made the 1.1.2 tarball on Friday, and was intending to cut the 1.2 tarball at the same time. However, preparations took a little longer than expected, so cutting the 1.2 tarball was delayed until Monday (US time). The official announcement of 1.1.2 and 1.2 will be made at the same time. In the interim, if you *really* need to use 1.1.2, you will probably be able to guess it's URL. The tarball won't change between now and the official announcement. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Django 1.1.2?
Hello, On the main Django page the official version is 1.1.1 but there is a new 1.1.2 version even documented if you make a search on the Django site. Is the 1.1.2 officialy supported? -- Antoni Aloy López Blog: http://trespams.com Site: http://apsl.net -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: 1.1.2
Thanks both. We'll use the 1.1 branch head then On Mar 11, 4:22 pm, James Bennett wrote: > On Wed, Mar 10, 2010 at 9:16 PM, brad wrote: > > When can we expect a release of 1.1.2? Specifically I'm hoping to get > > a test bug fixed -http://code.djangoproject.com/ticket/12720 > > Barring unforeseen circumstances, a 1.1.2 release will probably > accompany the release of Django 1.2. > > In the meantime, it's quite possible -- and at my day job we do this > with no ill effects -- to simply run off the head of the 1.1.X release > branch, periodically updating as needed. Since the release branches > *only* receive bugfixes and security updates, this is usually an easy > way to get fixes without waiting for point releases to be issued out > of it. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: 1.1.2
On Wed, Mar 10, 2010 at 9:16 PM, brad wrote: > When can we expect a release of 1.1.2? Specifically I'm hoping to get > a test bug fixed - http://code.djangoproject.com/ticket/12720 Barring unforeseen circumstances, a 1.1.2 release will probably accompany the release of Django 1.2. In the meantime, it's quite possible -- and at my day job we do this with no ill effects -- to simply run off the head of the 1.1.X release branch, periodically updating as needed. Since the release branches *only* receive bugfixes and security updates, this is usually an easy way to get fixes without waiting for point releases to be issued out of it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: 1.1.2
On Thu, Mar 11, 2010 at 11:16 AM, brad wrote: > Hi all > > When can we expect a release of 1.1.2? Specifically I'm hoping to get > a test bug fixed - http://code.djangoproject.com/ticket/12720 The most likely scenario is that we will cut 1.1.2 at the same time we cut 1.2-final. The exact date depends on progress through the 1.2 ticket list, but current estimates are around 3 weeks. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
1.1.2
Hi all When can we expect a release of 1.1.2? Specifically I'm hoping to get a test bug fixed - http://code.djangoproject.com/ticket/12720 Thanks Brad -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
