Re: sys.exit(1) from makemigrations if no changes found

2014-10-29 Thread Marc Tamlyn
I agree number 1 is fine. For most general interaction with the command users won't notice. Marc On 29 Oct 2014 02:04, "Andrew Godwin" wrote: > I'm actually fine with option 1 - always exiting with a status code if no > migrations are found. Since the status code does nothing useful at the > mom

Re: Websockets... again

2014-10-29 Thread Florian Apolloner
On Tuesday, October 28, 2014 11:37:15 PM UTC+1, mpaolini wrote: > > What if we do it with asyncio? > It is 3.4 only, WSGI still has no support for Websockets and the API would change drastically… -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Websockets... again

2014-10-29 Thread Aymeric Augustin
Then the first step is to throw away the ORM. See my talk at DjangoCon US 2013 for details. -- Aymeric. > Le 28 oct. 2014 à 23:36, Marco Paolini a écrit : > > What if we do it with asyncio? > > 2014-10-28 22:47 GMT+01:00 Aymeric Augustin > : >> No, there isn’t. >> >> I assume that “includi

Overwrite mode in collectstatic

2014-10-29 Thread Prathik Rajendran M
Hi all, This is to initiate a discussion on whether we should add a new overwrite method to collectstatic. Although I agree that we should careful in adding new features, I think this one is pretty useful. Here is why: - We want the files in STATIC_ROOT to be replaced even if the one there

Re: Overwrite mode in collectstatic

2014-10-29 Thread Tim Graham
For other readers, my analysis of the issue and why I don't think it's appropriate can be found on the ticket where the idea was first raised: https://code.djangoproject.com/ticket/23724 On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M wrote: > > Hi all, > > This is to initi

Django query in DetailView

2014-10-29 Thread Ronaldo Bahia
*This question is also in http://stackoverflow.com/questions/26635406/django-query-in-detailview I have DetailVIew wich returns a list of related objects (m2m throught). It works just fine! But I need to search for objects'names and it is returning all objects instead of only the related ones.

Re: Overwrite mode in collectstatic

2014-10-29 Thread Marc Tamlyn
I'd be inclined to agree with Tim, this seems to simply be a less useful version of --clear, for which the primary motivation was "we messed up". On 29 Oct 2014 16:05, "Tim Graham" wrote: > For other readers, my analysis of the issue and why I don't think it's > appropriate can be found on the ti

Re: Django query in DetailView

2014-10-29 Thread Tom Christie
Hi Ronaldo, This list is for the discussion of development *on the Django project itself*, not for discussion of usage questions when developing Django sites. You want the django-users mailing list, here: https://groups.google.com/forum/#!forum/django-users All the best, Tom On Wednesday,

Re: Websockets... again

2014-10-29 Thread Collin Anderson
Hi Luis, There is some work on making a WSGI2 that would include support for http/2 and likely websockets too. That would likely need to happen first or at the same time. https://github.com/python-web-sig/wsgi-ng You could also check out a project called "hendrix" which supports using websocke

Re: Websockets... again

2014-10-29 Thread Alex Gaynor
And after you throw away the ORM, you have to throw away every other library that does blocking IO (anything in the stdlib, memcached, redis, requests, etc.). There are absolutely no affordances in WSGI for use with non-blocking libraries like asyncio or Twisted. Alex On Wed Oct 29 2014 at 1:45:5

Re: Overwrite mode in collectstatic

2014-10-29 Thread Prathik Rajendran M
I'm happy if it is a fix for --clear either. The motivation is not "we messed up" but if in case someone else accidentally messed up nothing would happen unless they are aware of the what is going to happen, we make it clear that it will delete the existing files and get a prompt from them. My

Re: Overwrite mode in collectstatic

2014-10-29 Thread Prathik Rajendran M
And would love to hear on why you think of this as a less useful version. Would you suggest any changes to make it more useful? The end goal being that in scenarios where modified time of files in STATIC_ROOT is greater than that of the files in the APP, the files of the APP should replace the

Re: Overwrite mode in collectstatic

2014-10-29 Thread Tim Graham
"we make it clear that it will delete the existing files and get a prompt from them" Doesn't this already happen per the commits I linked in the ticket? "Unless the design decision of Django is that files directly written to STATIC_ROOT shouldn't be preserved," Yes, as the documentation for ST

Re: Overwrite mode in collectstatic

2014-10-29 Thread Prathik Rajendran M
Hi Tim, Doesn't this already happen per the commits I linked in the ticket? As far as I can see it tells that the existing files will be deleted, which is true, but it doesn't tell that the files of the STATIC_ROOT are same as the APP (in the scenario I mentioned) and that it can't be restored

Re: Overwrite mode in collectstatic

2014-10-29 Thread Tim Graham
I just don't see the value here. A problem happens if a user: 1) doesn't read the docs for STATIC_ROOT and sets it incorrectly AND 2) doesn't understand the following prompt: You have requested to collect static files at the destination location as specified in your settings: /home/tim/code/

Re: Overwrite mode in collectstatic

2014-10-29 Thread Shai Berger
I agree with Tim completely. I do see one thing that could help here: Add a check that STATIC_ROOT is not a subfolder of any app. This check cannot be really reliable (that is, a particularly careless and unlucky user could set things up so that their STATIC_ROOT is in an app but the check will

Re: sys.exit(1) from makemigrations if no changes found

2014-10-29 Thread Tim Heap
The backwards compatibility issue I was thinking of is for people using `makemigrations` in a script currently, expecting it to exit with 0 unless something very wrong has happened. For example, if `makemigrations` is run in a bash script with `set -e`, and it does not find any migrations, that

Re: sys.exit(1) from makemigrations if no changes found

2014-10-29 Thread Markus Holtermann
I like the general idea, but I slightly disagree with "As the command is instructed to make migrations, not making any is the error case.". Yes, grep works that way but I thing this are two different use cases. I think makemigrations on a project without any changes in the models' database repr

Add ability to show the migration plan (#23359)

2014-10-29 Thread Markus Holtermann
Hey folks, A few weeks ago I opened a ticket (https://code.djangoproject.com/ticket/23359) to add the ability to show a migration plan similar as listing all migrations within a project (manage.py migrate --list). After some discussions on IRC and on the first pull request (https://github.com/

Re: sys.exit(1) from makemigrations if no changes found

2014-10-29 Thread Tim Heap
I also agree that users should opt-in to enabling the error, using option 2 or 3, but I will implement what ever the popular option is. My argument regarding "As the command is instructed to make migrations, not making any is the error case." was more about when to return the error: either when

Re: sys.exit(1) from makemigrations if no changes found

2014-10-29 Thread Daryl
I'm +1 on being able to continue using the line ./manage.py makemigrations && ./manage.py migrate I can't see many (any?) situation where someone *wouldn't* run makemigrations & migrate as one logical operation, whether by typing the commands or running a script. What would the workflow be where y

Re: Add ability to show the migration plan (#23359)

2014-10-29 Thread Andrew Godwin
This used to be called "graphmigrations" in South, so I'm +0 on moving it to showmigrations; I don't want migrate to gain any extra functionality. That said, I tried moving --list to something separate during the 1.7 phase but there were objections to people who liked it on migrate. I don't really

Re: sys.exit(1) from makemigrations if no changes found

2014-10-29 Thread Tim Heap
If makemigrations exits with something other than 0, it will not have created any migrations to run anyway, so running the makemigrations & migrate pair here would not be affected. However, a useful one liner that I have been using when developing is: ./manage.py makemigrations && ./manage.py m

Re: Overwrite mode in collectstatic

2014-10-29 Thread Prathik Rajendran M
Let's say you run --clear often and in most cases it won't cause a problem and the same message is shown, let's say someone else in your team set the STATIC_FOLDER to a file in the app, in this case wouldn't you want an explicit message that unlike in the previous scenarios where STATIC_FOLDER