Re: LiveServerTestCase change in Django 1.11 means can't run functional tests against external server?

I learned this technique from Harry Percival's excellent > TDD with Python (see > http://chimera.labs.oreilly.com/books/123400754/ch08.html#_configuring_domains_for_staging_and_live), > where the test command is called from the local machine but you pass in the > external IP

Re: Migrations in Django 1.7 make unit testing models harder

y" to "ignore it completely", probably also in 1.9. > > Andrew > > > On Mon, Mar 31, 2014 at 4:15 PM, Harry Percival > > > wrote: > >> Just found out that you can make Django behave in the "old way" by just >> deleting the migrations f

Re: Migrations in Django 1.7 make unit testing models harder

rations should correctly detect this and insert blank strings for > you then. If not, open a bug report! > > Andrew > > > On Sun, Mar 30, 2014 at 5:13 AM, Shai Berger wrote: > >> On Sunday 30 March 2014 15:08:17 Harry Percival wrote: >> > Ah, so the reason I was c

Re: Migrations in Django 1.7 make unit testing models harder

Ah, so the reason I was confused is because it *looks* like the default is the empty string, because that's what you get if you initialise an object, by default. But at the database level, the default for the column is NULL. Is that right? So, I realise we're getting sidetracked here, but, how do

Re: LiveServerTestCase vs StaticLiveServerCase

sactionTestCase? The first will work in 90% of cases, the latter you can use if you have some more specialised requirements... On 29 March 2014 23:55, Carl Meyer wrote: > On 03/29/2014 02:36 PM, Shai Berger wrote: > > On Saturday 29 March 2014 19:11:17 Harry Percival wrote: > >>

Re: Migrations in Django 1.7 make unit testing models harder

Provide a one-off default now (will be set on all existing rows) 2) Quit, and let me add a default in models.py I thought TextField did have a default, the empty string? On 29 March 2014 19:15, Harry Percival wrote: > I suspect you're probably right. Having to run makemigrations i

Re: Migrations in Django 1.7 make unit testing models harder

ashmigrations exists to deal with this > problem and move on. > > Andrew > > > On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival > wrote: > >> Am just working on updating my book on TDD to django 1.7 based on the >> beta. Currently half-way thru, not run into a

Re: LiveServerTestCase vs StaticLiveServerCase

StaticLiveServerCase. On 29 March 2014 18:10, Ramiro Morales wrote: > On Sat, Mar 29, 2014 at 1:26 PM, Harry Percival > wrote: > > > > > [...] > > > > But I just wanted to express the fact that it feels a little > > counter-intuitive. I don't

Re: Migrations in Django 1.7 make unit testing models harder

Am just working on updating my book on TDD to django 1.7 based on the beta. Currently half-way thru, not run into any problems because I don't use migrations until a later chapter, but when I do I will run into the same problems Bernie mentions. Will share more once I've finished the rewrites

LiveServerTestCase vs StaticLiveServerCase

Just updating my book to using the django 1.7 beta. I use LiveServerTestCase a lot. I used to rely on the fact that LiveServerTestCase "magically" serves static files from app folders. I see the default functionality is that this no longer works, but I can get it by switching to StaticLiveS

Re: Should exceptions in dev server appear as tracebacks in the console by default?

command, and only if DEBUG* is set to True. Is that correct? On 3 January 2014 15:44, Harry Percival wrote: > Thanks Tim, let me make sure I understand the current functionality: > > - django.request is the logger for views (broadly speaking) any logging > "elsewhere" woul

Re: Should exceptions in dev server appear as tracebacks in the console by default?

hat added that documentation and the related > ticket helpful: > https://github.com/django/django/commit/f0f327bb > https://code.djangoproject.com/ticket/18993 > > Documentation improvements would be welcome if you feel they are > appropriate. > > > On Saturday, Decembe

Should exceptions in dev server appear as tracebacks in the console by default?

The docs say: *"All messages reaching the django catch-all logger when DEBUG is True are sent to the console. They are simply discarded (sent to NullHandler) when DEBUG

Re: LiveServerTestCase, and override_settings(DEBUG=True)

Thanks gang. @Russell, I assume you meant set MEDIA_URL = "/media/" That works if I do it in settings.py. Interestingly, it doesn't work if I try and do it via override_settings? On Thursday, 19 December 2013 08:16:59 UTC, Aymeric Augustin wrote: > > On 19 déc. 2013, at 02:14, Russell Keith-

Re: Creating a minimal custom user model. Seems last_login is required. Should it be?

Hi all, can't believe I missed this entire thread because googlegroups didn't auto-subscribe me to replies. thanks for the tips. For the curious, I'm using Mozilla Persona. Detailed info here: http://chimera.labs.oreilly.com/books/123400754/ch14.html On Monday, 21 October 2013 15:22:07 UT

LiveServerTestCase, and override_settings(DEBUG=True)

Django's test runner overrides your settings to force DEBUG to be True, which I understand the intention behind, but it is occasionally annoying. One solution for those cases is to use `override_settings`, but that has very weird effects when using `LiveServerTestCase`. Minimal repro: dja

Creating a minimal custom user model. Seems last_login is required. Should it be?

I'm trying to create a minimal custom user model. The only thing I care about is email. But it seems Django really wants me to set a last_login field. Can I avoid it somehow? Here's the minimal repro: https://github.com/hjwp/minimal-django-custom-user-model/commit/377a83a9c995b2346b79458dcb5

Re: I'd like to make a contribution to the wiki

ion -- 404 On Thursday, November 29, 2012 11:29:29 PM UTC, Russell Keith-Magee wrote: Hi Harry, That particular page has been locked down due to problems we've had with spam. If you let us know what you want to add, I can add an entry to the list on your behalf. Yours, Russ Magee

Re: I'd like to make a contribution to the wiki

nywhere.com/ (user/pass: test/test) it went pretty > well. Great work ! > > One question thought, most of the time, free accounts disappear at some > point, when the company grows. Are you committed to maintaining free > accounts ? > > Thanks for answering > > &g

I'd like to make a contribution to the wiki

It's for promotional purposes really - I want to add my employers, PythonAnywhere, to the list of Django-Friendly-Web-Hosts https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts But it's not entirely one-sided and evil-marketing-spammy. We do offer Django hosting as part of our Free pla