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
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
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
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
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
*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.
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
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,
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
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
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
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
"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
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
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/
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
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
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
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/
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
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
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
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
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
24 matches
Mail list logo