Re: Please put monitor.py as default in next django version

[Curtis Maloney]

On 15/10/16 08:16, Ricardo Prado wrote:

Thanks "Folks" in special Aymeric

Let's go, let me explain about this "monitor.py".

When users deploy django app in production, the changes in any python
script need be "reloaded" for apply changes, in this you have two
options to do this:

1 - restart apache or nginx server


Well, no... if you're using apache/mod_wsgi (and have configured it 
correctly) you merely need to "touch" the wsgi script.


If you're using nginx, it doesn't run django, so you should be starting 
whichever uwsgi service you are using (e.g. uwsgi, gunicorn, waitress, etc)



Anyway this is a problem, this file can be included in django core for
apply changes in python script and don't need be reload server. When you
start a django app

typing: "python manage.py runserver".

An internal montior is initialized for apply changes runtime. Would be
good have this option in production too.


Most deploy processes and managers would scream at you if you decided to 
restart the service every time a file changed.


Typically in production you want to update the whole codebase and have a 
controlled reload (is touch really so difficult?)


What sort of situations are you seeing that you want a restart 
frequently and more simple than "touch wsgi.py" ?


--
C

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/672f21be-7524-9c22-173b-2ddefe93444e%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Please put monitor.py as default in next django version

[Jeremy Spencer]

Hello,

I agree with Florian. Deployments are not the same across the board. It is
also simple enough to write something like a fabric script that handles
your own unique process accordingly.

 This would make an excellent additional package on pypi, but I do not see
a reason to include it as a default in Django.

Jeremy

On Fri, Oct 14, 2016 at 7:48 PM Florian Apolloner 
wrote:

> Hi,
>
>
> On Saturday, October 15, 2016 at 1:38:32 AM UTC+2, Ricardo Prado wrote:
>
> An internal montior is initialized for apply changes runtime. Would be
> good have this option in production too.
>
>
> I tend to disagree. Having this in production would be kind of bad -- it
> takes extra resources and does not provide any benefit. After all
> deployments are a controlled action, reloading your webserver (or whatever
> your strategy requires) should be part of deployment and not be part of
> Django (which cannot really know what you WSGI handler needs anyways).
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16a2ecc2-42b0-46d6-9f7b-5758c0eafc7c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

---
Jeremy Spencer
www.jeremyspencer.me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACfg-bjam0X4XSNg-m4NcjQHtoaX3PXz4wQbrnHki_LO52qR_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please put monitor.py as default in next django version

[Florian Apolloner]

Hi,

On Saturday, October 15, 2016 at 1:38:32 AM UTC+2, Ricardo Prado wrote:
>
> An internal montior is initialized for apply changes runtime. Would be 
> good have this option in production too.
>

I tend to disagree. Having this in production would be kind of bad -- it 
takes extra resources and does not provide any benefit. After all 
deployments are a controlled action, reloading your webserver (or whatever 
your strategy requires) should be part of deployment and not be part of 
Django (which cannot really know what you WSGI handler needs anyways).

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/16a2ecc2-42b0-46d6-9f7b-5758c0eafc7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please put monitor.py as default in next django version

[Ricardo Prado]

Thanks "Folks" in special Aymeric

Let's go, let me explain about this "monitor.py".

When users deploy django app in production, the changes in any python 
script need be "reloaded" for apply changes, in this you have two options 
to do this:

1 - restart apache or nginx server
2 - "touch wsgi.py" (command line linux)

Anyway this is a problem, this file can be included in django core for 
apply changes in python script and don't need be reload server. When you 
start a django app

typing: "python manage.py runserver".

An internal montior is initialized for apply changes runtime. Would be good 
have this option in production too.


Attachment:
monitor.py sample and wsgi.py in usage.

Thanks!



Em quinta-feira, 13 de outubro de 2016 22:39:31 UTC-3, Ricardo Prado 
escreveu:
>
> Hy Guys!
>
> A always use monitor.py to developer my django apps, but this file ins't 
> included in django current version. In future this can be included for dev 
> tools.
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67a0d82b-4d33-471f-a15c-ef7921f97457%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
import os
import sys
import time
import signal
import threading
import atexit
import Queue

_interval = 1.0
_times = {}
_files = []

_running = False
_queue = Queue.Queue()
_lock = threading.Lock()

def _restart(path):
_queue.put(True)
prefix = 'monitor (pid=%d):' % os.getpid()
print >> sys.stderr, '%s Change detected to \'%s\'.' % (prefix, path)
print >> sys.stderr, '%s Triggering process restart.' % prefix
os.kill(os.getpid(), signal.SIGINT)

def _modified(path):
try:
# If path doesn't denote a file and were previously
# tracking it, then it has been removed or the file type
# has changed so force a restart. If not previously
# tracking the file then we can ignore it as probably
# pseudo reference such as when file extracted from a
# collection of modules contained in a zip file.

if not os.path.isfile(path):
return path in _times

# Check for when file last modified.

mtime = os.stat(path).st_mtime
if path not in _times:
_times[path] = mtime

# Force restart when modification time has changed, even
# if time now older, as that could indicate older file
# has been restored.

if mtime != _times[path]:
return True
except:
# If any exception occured, likely that file has been
# been removed just before stat(), so force a restart.

return True

return False

def _monitor():
while 1:
# Check modification times on all files in sys.modules.

for module in sys.modules.values():
if not hasattr(module, '__file__'):
continue
path = getattr(module, '__file__')
if not path:
continue
if os.path.splitext(path)[1] in ['.pyc', '.pyo', '.pyd']:
path = path[:-1]
if _modified(path):
return _restart(path)

# Check modification times on files which have
# specifically been registered for monitoring.

for path in _files:
if _modified(path):
return _restart(path)

# Go to sleep for specified interval.

try:
return _queue.get(timeout=_interval)
except:
pass

_thread = threading.Thread(target=_monitor)
_thread.setDaemon(True)

def _exiting():
try:
_queue.put(True)
except:
pass
_thread.join()

atexit.register(_exiting)

def track(path):
if not path in _files:
_files.append(path)

def start(interval=1.0):
global _interval
if interval < _interval:
_interval = interval

global _running
_lock.acquire()
if not _running:
prefix = 'monitor (pid=%d):' % os.getpid()
print >> sys.stderr, '%s Starting change monitor.' % prefix
_running = True
_thread.start()
_lock.release()
import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "framework.settings")

application = get_wsgi_application()


import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "framework.settings")

application = get_wsgi_application()

from framework import settings

if settings.DEBUG:
	import framework.monitor
	framework.monitor.start(interval=1.0)

Re: (contrib.admin) Improving object deletion

[Olivier Dalang]

On the same topic (I'm not really sure whether it's not the same thing
you're talking about), currently, even if a user has not the permission to
delete an object via the change form (because of some custom logic in
modeladmin.has_delete_permission(request,obj) ), he can delete it via the
batch delete tool.

I think it's not really consistent, arguably a bug.

I guess this is the case because we use Queryset.delete(), which doesn't
allow for per-instance permission checking.

To me, the cleanest way to deal with this would be :

- have the default delete_selected action take
modeladmin.has_delete_permission(request,obj), and by the way, have the
default delete_selected use Model.delete() instead of Queryset.delete()
- provide a non default delete_selected_fast action work like the current
delete_selected action








2016-10-14 15:31 GMT+00:00 Tim Graham :

> Here is a ticket about the memory issue: https://code.djangoproject.
> com/ticket/10919
>
> It's hard for me to evaluate the other idea without looking at the code.
> If you want to open a ticket and provide a patch, go ahead.
>
> On Friday, October 14, 2016 at 9:08:16 AM UTC-4, Marcin Nowak wrote:
>>
>> Hi all.
>>
>> Sometimes there is huge amount of related objects. In the effect there is
>> no possibility to delete a model because of http timeout error.
>> Displaying objects to be deleted is quite nice feature, but just unusable
>> in cases like that.
>>
>> Another thing is that nobody will read 74k related objects. Believe me.
>> It is better to display a summary in that case.
>> To display the summary, a related objects must be counted and this is
>> time consuming process, of course, but we can count them similar way to
>> Collector's fast deletion (using querysets instead of counting models one
>> by one).
>>
>> There is also other design flaw in ModelAdmin.delete_view() - related
>> objects are counted twice: one time for display, and second time after
>> confirming deletion (for request.method==POST). For the second case django
>> is checking only permissions and collected objects aren't used for anything
>> else. Until Django provides no row-level permissions checking those can be
>> done without instantiating all related objects again.
>>
>> I'd like to suggest:
>>
>>- separation of permissions checking from related objects collector,
>>- adding configration option for ModelAdmin.delete_view (to display
>>related objects, display summary, or finally display nothing).
>>
>> Thank you.
>>
>> Marcin.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/fb2c2044-241f-4ea6-9db2-
> ec2dafebbeb5%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAExk7p1dYqhbna5n78f0qGQR0g3qFZ1PRhH5rBQwbyFTcGzGfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: (contrib.admin) Improving object deletion

[Michal Petrucha]

Marcin Nowak  skrev: (14 oktober 2016 15:08:15 CEST)
>Hi all.
>
>Sometimes there is huge amount of related objects. In the effect there
>is 
>no possibility to delete a model because of http timeout error.
>Displaying objects to be deleted is quite nice feature, but just
>unusable 
>in cases like that. 
>
>Another thing is that nobody will read 74k related objects. Believe me.
>It 
>is better to display a summary in that case. 
>To display the summary, a related objects must be counted and this is
>time 
>consuming process, of course, but we can count them similar way to 
>Collector's fast deletion (using querysets instead of counting models
>one 
>by one).
>
>There is also other design flaw in ModelAdmin.delete_view() - related 
>objects are counted twice: one time for display, and second time after 
>confirming deletion (for request.method==POST). For the second case
>django 
>is checking only permissions and collected objects aren't used for
>anything 
>else. Until Django provides no row-level permissions checking those can
>be 
>done without instantiating all related objects again.

Even though Django doesn't include an implementation of object-level 
permissions, it does expose a public API for third-party packages to implement 
them. It probably wouldn't be appropriate to break those, but it might be 
feasible to make it possible to opt into the fast path explicitly. 

>
>I'd like to suggest:
>
>   - separation of permissions checking from related objects collector,
>   - adding configration option for ModelAdmin.delete_view (to display 
>   related objects, display summary, or finally display nothing).
>
>Thank you.
>
>Marcin.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FB429CA3-5FDD-406B-9F38-71FE1BBFD2B9%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: (contrib.admin) Improving object deletion

[Tim Graham]

Here is a ticket about the memory issue: 
https://code.djangoproject.com/ticket/10919

It's hard for me to evaluate the other idea without looking at the code. If 
you want to open a ticket and provide a patch, go ahead.

On Friday, October 14, 2016 at 9:08:16 AM UTC-4, Marcin Nowak wrote:
>
> Hi all.
>
> Sometimes there is huge amount of related objects. In the effect there is 
> no possibility to delete a model because of http timeout error.
> Displaying objects to be deleted is quite nice feature, but just unusable 
> in cases like that. 
>
> Another thing is that nobody will read 74k related objects. Believe me. It 
> is better to display a summary in that case. 
> To display the summary, a related objects must be counted and this is time 
> consuming process, of course, but we can count them similar way to 
> Collector's fast deletion (using querysets instead of counting models one 
> by one).
>
> There is also other design flaw in ModelAdmin.delete_view() - related 
> objects are counted twice: one time for display, and second time after 
> confirming deletion (for request.method==POST). For the second case django 
> is checking only permissions and collected objects aren't used for anything 
> else. Until Django provides no row-level permissions checking those can be 
> done without instantiating all related objects again.
>
> I'd like to suggest:
>
>- separation of permissions checking from related objects collector,
>- adding configration option for ModelAdmin.delete_view (to display 
>related objects, display summary, or finally display nothing).
>
> Thank you.
>
> Marcin.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fb2c2044-241f-4ea6-9db2-ec2dafebbeb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

(contrib.admin) Improving object deletion

[Marcin Nowak]

Hi all.

Sometimes there is huge amount of related objects. In the effect there is 
no possibility to delete a model because of http timeout error.
Displaying objects to be deleted is quite nice feature, but just unusable 
in cases like that. 

Another thing is that nobody will read 74k related objects. Believe me. It 
is better to display a summary in that case. 
To display the summary, a related objects must be counted and this is time 
consuming process, of course, but we can count them similar way to 
Collector's fast deletion (using querysets instead of counting models one 
by one).

There is also other design flaw in ModelAdmin.delete_view() - related 
objects are counted twice: one time for display, and second time after 
confirming deletion (for request.method==POST). For the second case django 
is checking only permissions and collected objects aren't used for anything 
else. Until Django provides no row-level permissions checking those can be 
done without instantiating all related objects again.

I'd like to suggest:

   - separation of permissions checking from related objects collector,
   - adding configration option for ModelAdmin.delete_view (to display 
   related objects, display summary, or finally display nothing).

Thank you.

Marcin.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a38bd871-459d-4783-a435-c42de02310d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please put monitor.py as default in next django version

[Aymeric Augustin]

Hello Ricardo,

I looked for monitor.py but I’m not sure what you’re referring to. I don’t know 
what you call the “dev tools” either; If you’re thinking of the debug toolbar 
 it’s a third party project. 
To move forwards with this, you’ll have to clarify your suggestion.

Thanks,

-- 
Aymeric.

PS: hopefully you’re writing to all people on this mailing list and not only 
men. May I suggest “hello folks” rather than “hello guys” for next time? This 
isn’t a boys’ club.


> On 14 Oct 2016, at 01:13, Ricardo Prado  wrote:
> 
> Hy Guys!
> 
> A always use monitor.py to developer my django apps, but this file ins't 
> included in django current version. In future this can be included for dev 
> tools.
> 
> Thanks.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c32385f6-a105-4fce-b1ec-b856b017cca6%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8323CB0B-917C-459C-9CD0-4C50CA9C0687%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.