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

[Harry Percival]

in the
> external IP.  Will there be a different way to do this in Django 1.11?
> Perhaps the change to bind LiveserverTestCase to port zero by default can
> be made while retaining the option to pass in --liveserver?  Realize the
> release is a ways away but would appreciate any help as I've come to rely
> on this method to test server deployments.  Thank you!
>
> --

--
Harry Percival
+44 78877 02511

-- 
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/CACFvh9-G1YpnksGnqsujjq3XncomAL8TAZOQfX%3D2PLO0qofV%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

Well, having stayed up til 4AM on Monday night, I managed to get the whole 
book upgraded to Django 1.7, and published.  I've shared some thoughts on 
the migrations / tdd stuff we've been discussing, here:

http://www.obeythetestinggoat.com/book-upgraded-to-django-17.html

I'd be very interested in ppl's comments, particularly on the part of the 
book in which I introduce migrations:  am I saying the right things, am I 
giving people the right / best practice habits, etc.

http://chimera.labs.oreilly.com/books/123400754/ch05.html#_the_django_orm_amp_our_first_model

I think my overall conclusion is that the new migrations framework does 
involve a bit more pain, when doing tdd or when introducing newbies to 
django, but that that pain is worthwhile, since it's stuff that would come 
back and bite you later when you gloss over it (which you used to be able 
to do).

cheers all!
HP

On Tuesday, 1 April 2014 00:32:22 UTC+1, Andrew Godwin wrote:
>
> Yes, you can - the "migrations or not" switch is currently "is there a 
> migrations directory", but bear in mind this will eventually turn from "use 
> the old way" to "ignore it completely", probably also in 1.9.
>
> Andrew
>
>
> On Mon, Mar 31, 2014 at 4:15 PM, Harry Percival 
> <harry.p...@gmail.com
> > wrote:
>
>> Just found out that you can make Django behave in the "old way" by just 
>> deleting the migrations folder when you first do your `startapp`, and then 
>> you can pretend migrations don't exist until you need them.  Don't think 
>> that's necessarily a good idea though...
>>
>>
>> On 30 March 2014 19:42, Andrew Godwin <and...@aeracode.org 
>> >wrote:
>>
>>> You're roughly right, yes. String fields are a little odd, though, in 
>>> that you can have them blank=True without null=True and then the default 
>>> should be an empty string (Django's separation of blank and null irks me 
>>> still) - the migrations 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 
>>> <sh...@platonix.com
>>> > wrote:
>>>
>>>> On Sunday 30 March 2014 15:08:17 Harry Percival wrote:
>>>> > 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 does this fit 
>>>> with
>>>> > the fact that `null=False` is the default for all Field types?
>>>> >
>>>>
>>>> Simply: The "default default" is that fields are required.
>>>>
>>>> But this is very deep in django-users territory.
>>>>
>>>> Shai.
>>>>
>>>> --
>>>>
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Django developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to django-develop...@googlegroups.com .
>>>>
>>>> To post to this group, send email to 
>>>> django-d...@googlegroups.com
>>>> .
>>>> Visit this group at http://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/django-developers/201403301513.23581.shai%40platonix.com
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com .
>>>
>>> To post to this group, send email to 
>>> django-d...@googlegroups.com
>>> .
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CAFwN1urwhyZkfF9smfeeSOeS_8ej

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

Just found out that you can make Django behave in the "old way" by just
deleting the migrations folder when you first do your `startapp`, and then
you can pretend migrations don't exist until you need them.  Don't think
that's necessarily a good idea though...


On 30 March 2014 19:42, Andrew Godwin <and...@aeracode.org> wrote:

> You're roughly right, yes. String fields are a little odd, though, in that
> you can have them blank=True without null=True and then the default should
> be an empty string (Django's separation of blank and null irks me still) -
> the migrations 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 <s...@platonix.com> wrote:
>
>> On Sunday 30 March 2014 15:08:17 Harry Percival wrote:
>> > 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 does this fit
>> with
>> > the fact that `null=False` is the default for all Field types?
>> >
>>
>> Simply: The "default default" is that fields are required.
>>
>> But this is very deep in django-users territory.
>>
>> Shai.
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/201403301513.23581.shai%40platonix.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1urwhyZkfF9smfeeSOeS_8ejFdKmKo3X%3D4yfWd8DGU_%3DTA%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAFwN1urwhyZkfF9smfeeSOeS_8ejFdKmKo3X%3D4yfWd8DGU_%3DTA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

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

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

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 does this fit with
the fact that `null=False` is the default for all Field types?


On 29 March 2014 23:37, Ryan Hiebert  wrote:

> I thought TextField did have a default, the empty string?
>>
>> Like every other field, the "default default" is None (NULL).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABpHFHQK9UdEK6x4Mb3eDqXd5f%3D9egzJp5A21UZYXAQJw8HRDw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

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

Re: LiveServerTestCase vs StaticLiveServerCase

[Harry Percival]

In that case, maybe the question is:  which should be the default?

Given that, as you say, most people use staticfiles, it feels to me like
the test case in which static files "just work", without having to remember
to run `collectstatic` before each test run, would feel like a good default.

More advanced users who are managing their static assets totally
differently -- on a CDN, say -- can then use the more restrictive
LiveServerTestCase if they want to.  Although the default test case would
still work just fine for them.

Maybe there's a parallel with TestCase and TransactionTestCase? 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 <c...@oddbird.net> wrote:

> On 03/29/2014 02:36 PM, Shai Berger wrote:
> > On Saturday 29 March 2014 19:11:17 Harry Percival wrote:
> >>
> >> What I *am* saying is that, in my opinion, there's not much point in
> >> LiveServerTestCase if it doesn't do static files.  So, to keep things
> >> simple, it would be simpler to remove it, and just have on LiveServer
> test
> >> class, that lives in .contrib if it has to...
> >>
> >> But maybe others would disagree?
> >>
> >> To explain a bit more -- what is LiveServerTestCase for?  It's to let
> you
> >> run tests with (eg) selenium, against a "real" web server.  And one of
> the
> >> most obvious reasons to do that is to test client-side stuff like
> >> javascript, ie stuff that depends on static files.  And so that means
> that
> >> you have to either run collectstatic before every test run, or switch to
> >> StaticLiveServerCase.
> >>
> >
> > FWIW, I've been using LiveServerTestCase to test an app that, in some
> > circumstances, needs to send requests to other servers; in essence,
> mocking
> > those other servers. It's been very useful for this, and it does not
> require
> > any statics.
> >
> > Granted, that is a fringe case, and the main use-case remains tests
> involving
> > real browsers. Just pointing out that a LiveServerTestCase with no
> support for
> > statics does have real uses.
>
> Contrib.staticfiles is an optional way of handling static assets in
> Django. It probably is the most commonly-used way, but it is not
> required. It is possible to write a fully-functional Django project that
> uses static assets without using contrib.staticfiles to manage them.
>
> IMO this is good enough reason for both LiveServerTestCase and
> StaticLiveServerTestCase to exist.
>
> Carl
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/SYktTEJXWc8/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/53375D83.8060209%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

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

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

OK, I've now run into the problem IRL, and sure enough, it's different to
what i'm used to.  Am trying to overcome my knee-jerk reactions of "why did
it change! i hate it!".  ignoring that for a moment then:

One thing I did find surprising was that I'm going thru TDD in small steps
like this:

class Item(models.Model):
pass

- create migration 001-initial, with Item and auto-id

class Item(models.Model):
text = models.TextField()

- create migration 0002, adding the item field.  here's where we get into
the discussion of too many migrations, wanting to squash, etc etc etc.

leaving that aside for a moment, i was taken aback by this:

You are trying to add a non-nullable field 'text' to item without a default;
we can't do that (the database needs something to populate existing rows).
Please select a fix:
 1) 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 <harry.perci...@gmail.com> wrote:

> I suspect you're probably right.  Having to run makemigrations in between
> making changes to model code and running tests isn't the end of the world i
> suppose.  Will know better what I'm talking about  when I've actually got
> to that part of the book...
>
>
> On 29 March 2014 18:23, Andrew Godwin <and...@aeracode.org> wrote:
>
>> No, there is no way to turn off migrations for tests - some of the core
>> tests won't work without them turned on, in fact, and adding that option
>> would be weird (why only tests? what would it do? how do you load data in
>> now initial_data is gone?). The only complaint I've seen - the one that
>> Bernie brought up originally, that it's "extra work" to run makemigrations
>> before each test run - doesn't really hold water with me, as the
>> alternative options mean you could run the tests and have them pass WITHOUT
>> HAVING THE RIGHT MIGRATIONS - and so you're not testing part of your
>> codebase.
>>
>> Hell, you can alias together makemigrations and test if you want, that'll
>> save you the typing. This might make a few more migrations than normal, but
>> you could quickly point out that squashmigrations exists to deal with this
>> problem and move on.
>>
>> Andrew
>>
>>
>> On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival <harry.perci...@gmail.com
>> > 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 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, but from what I see so
>>> far, I think I'd personally prefer to be able to run my tests without
>>> having to remember to call makemigrations every time.  some kind of
>>> customisable option?  either a command-line flag for the test runner, or
>>> maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?
>>>
>>> personally i'd like the default to be true, but i can appreciate other
>>> people will have different workflows / assumptions.
>>>
>>>
>>>
>>>
>>> On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>>>
>>>> Yes, --update is very risky if you run it on migrations that are
>>>> already committed and pushed, but the main reason I left it out of 1.7 was
>>>> complexity (because makemigrations is now much more intelligent, updating
>>>> and adding a foreignkey into a migration might introduce a new dependency
>>>> or force a new migration anyway). Given that we have the ability to safely
>>>> squash large numbers of small migrations down into one with
>>>> squashmigrations and distribute that to fix the many-small-migrations
>>>> problem, I considered it pretty low priority, though I have a rough idea of
>>>> how I could make it work (I'd have to load up the autodetector with the
>>>> existing migrations already loaded in as a halfway state and then run it
>>>> from there, which should produce the right result).
>>>>
>>>> Anyway, if you're retracting your original request, I'm happy to leave
>>>> this for the 1.7 release; I don't think there's a good solution that Django
>>>> core can implement effectively. This reminds me of when people used to ask
>>>> me to automatically stop their developers writing conflicting migrations -
>>>> the solut

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

I suspect you're probably right.  Having to run makemigrations in between
making changes to model code and running tests isn't the end of the world i
suppose.  Will know better what I'm talking about  when I've actually got
to that part of the book...


On 29 March 2014 18:23, Andrew Godwin <and...@aeracode.org> wrote:

> No, there is no way to turn off migrations for tests - some of the core
> tests won't work without them turned on, in fact, and adding that option
> would be weird (why only tests? what would it do? how do you load data in
> now initial_data is gone?). The only complaint I've seen - the one that
> Bernie brought up originally, that it's "extra work" to run makemigrations
> before each test run - doesn't really hold water with me, as the
> alternative options mean you could run the tests and have them pass WITHOUT
> HAVING THE RIGHT MIGRATIONS - and so you're not testing part of your
> codebase.
>
> Hell, you can alias together makemigrations and test if you want, that'll
> save you the typing. This might make a few more migrations than normal, but
> you could quickly point out that squashmigrations exists to deal with this
> problem and move on.
>
> Andrew
>
>
> On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival 
> <harry.perci...@gmail.com>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 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, but from what I see so
>> far, I think I'd personally prefer to be able to run my tests without
>> having to remember to call makemigrations every time.  some kind of
>> customisable option?  either a command-line flag for the test runner, or
>> maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?
>>
>> personally i'd like the default to be true, but i can appreciate other
>> people will have different workflows / assumptions.
>>
>>
>>
>>
>> On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>>
>>> Yes, --update is very risky if you run it on migrations that are already
>>> committed and pushed, but the main reason I left it out of 1.7 was
>>> complexity (because makemigrations is now much more intelligent, updating
>>> and adding a foreignkey into a migration might introduce a new dependency
>>> or force a new migration anyway). Given that we have the ability to safely
>>> squash large numbers of small migrations down into one with
>>> squashmigrations and distribute that to fix the many-small-migrations
>>> problem, I considered it pretty low priority, though I have a rough idea of
>>> how I could make it work (I'd have to load up the autodetector with the
>>> existing migrations already loaded in as a halfway state and then run it
>>> from there, which should produce the right result).
>>>
>>> Anyway, if you're retracting your original request, I'm happy to leave
>>> this for the 1.7 release; I don't think there's a good solution that Django
>>> core can implement effectively. This reminds me of when people used to ask
>>> me to automatically stop their developers writing conflicting migrations -
>>> the solution varies from company to company and often isn't technical but
>>> just education or communication.
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption 
>>> <ber...@berniecode.com>wrote:
>>>
>>>> South's `--update` also rolled the previous migration back, changed it
>>>>> and then reapplied it to the current database.
>>>>>
>>>>
>>>> OK, in that case I can very much see how it's useful for people who
>>>> develop against a persistent database. That's probably most people.
>>>>
>>>> Anyway, the result of this thread for me is that I now consider my
>>>> original request to be obsolete, as the "git clean" thing is a simple way
>>>> of getting the behaviour I want for my own style of TDD without hacks.
>>>>
>>>> Thanks for your time.
>>>>
>>>> Bernie :o)
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@goo

Re: LiveServerTestCase vs StaticLiveServerCase

[Harry Percival]

Well, neither, really, but, if anything, the latter.

- I don't think there's any bugs in StaticLiveServerCase.

- I have changed all my tests to use the new class.  it wasn't the end of
the world.

What I *am* saying is that, in my opinion, there's not much point in
LiveServerTestCase if it doesn't do static files.  So, to keep things
simple, it would be simpler to remove it, and just have on LiveServer test
class, that lives in .contrib if it has to...

But maybe others would disagree?

To explain a bit more -- what is LiveServerTestCase for?  It's to let you
run tests with (eg) selenium, against a "real" web server.  And one of the
most obvious reasons to do that is to test client-side stuff like
javascript, ie stuff that depends on static files.  And so that means that
you have to either run collectstatic before every test run, or switch to
StaticLiveServerCase.






On 29 March 2014 18:10, Ramiro Morales <cra...@gmail.com> wrote:

> On Sat, Mar 29, 2014 at 1:26 PM, Harry Percival
> <harry.perci...@gmail.com> wrote:
>
> >
> > [...]
> >
> > But I just wanted to express the fact that it feels a little
> > counter-intuitive.   I don't know enough to weigh how important it is to
> > remove a dependency on a contrib app from the testcases framework, but,
> as a
> > user, having to remember that i need to run `collectstatic` before all my
> > tests will pass is a bit weird. collectstatic is something i do on
> servers,
> > not on my local dev box. and LiveServerTestCase isn't much use without
> > working static files.
>
> Are you saying that you need to run collectstatic before all your tests
> when you make your test cases inherit from StaticLiveServerCase instead
> of LiveServerTestCase?. Because if so, that's a bug I'd need to fix because
> that's not the intended behavior and I'm the one behind this change.
>
> Or are you saying that you don't want to bother to edit your tests code
> to replace StaticLiveServerCase with LiveServerTestCase as part of your
> migration to 1.7?
>
> Regards,
>
> --
> Ramiro Morales
> @ramiromorales
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/SYktTEJXWc8/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAO7PdF9xTf7rtLtemaSHUXeX8eqc7oR7wD-%3DZyL9LedjQ7ZxRA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

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

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

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, but from what I see so 
far, I think I'd personally prefer to be able to run my tests without 
having to remember to call makemigrations every time.  some kind of 
customisable option?  either a command-line flag for the test runner, or 
maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?

personally i'd like the default to be true, but i can appreciate other 
people will have different workflows / assumptions.



On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>
> Yes, --update is very risky if you run it on migrations that are already 
> committed and pushed, but the main reason I left it out of 1.7 was 
> complexity (because makemigrations is now much more intelligent, updating 
> and adding a foreignkey into a migration might introduce a new dependency 
> or force a new migration anyway). Given that we have the ability to safely 
> squash large numbers of small migrations down into one with 
> squashmigrations and distribute that to fix the many-small-migrations 
> problem, I considered it pretty low priority, though I have a rough idea of 
> how I could make it work (I'd have to load up the autodetector with the 
> existing migrations already loaded in as a halfway state and then run it 
> from there, which should produce the right result).
>
> Anyway, if you're retracting your original request, I'm happy to leave 
> this for the 1.7 release; I don't think there's a good solution that Django 
> core can implement effectively. This reminds me of when people used to ask 
> me to automatically stop their developers writing conflicting migrations - 
> the solution varies from company to company and often isn't technical but 
> just education or communication.
>
> Andrew
>
>
> On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption 
>  > wrote:
>
>> South's `--update` also rolled the previous migration back, changed it 
>>> and then reapplied it to the current database.
>>>
>>
>> OK, in that case I can very much see how it's useful for people who 
>> develop against a persistent database. That's probably most people.
>>
>> Anyway, the result of this thread for me is that I now consider my 
>> original request to be obsolete, as the "git clean" thing is a simple way 
>> of getting the behaviour I want for my own style of TDD without hacks.
>>
>> Thanks for your time.
>>
>> Bernie :o)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8e3ecf3c-aa05-4e3d-b905-3260b093e046%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" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a2897318-ec81-4acd-b201-2591042db1a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

LiveServerTestCase vs StaticLiveServerCase

[Harry Percival]

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 
StaticLiveServerTestCase.  great, glad to see that was built for backwards 
compatibility, I'll switch to using that, so no immediate problem.  i am, 
as always, eternally gratefully to everyone involved for their 
thoughtfulness.

But I just wanted to express the fact that it feels a little 
counter-intuitive.   I don't know enough to weigh how important it is to 
remove a dependency on a contrib app from the testcases framework, but, as 
a user, having to remember that i need to run `collectstatic` before all my 
tests will pass is a bit weird. collectstatic is something i do on servers, 
not on my local dev box. and LiveServerTestCase isn't much use without 
working static files.

So I guess I'm saying, how about just moving LiveServerTestCase into 
contrib, and merging it with StaticLiveServerTestCase??


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c0868046-2147-486b-8c2c-06f3cd5ca8af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Harry Percival]

so, just to rephrase this, to help think about how the docs could be
improved. If I understand things correctly:

*with the default settings, the only circumstances in which a logging
message would end up in the console is outside of normal django request
handling, for example in a management command, and only if DEBUG* is set to
True.

Is that correct?



On 3 January 2014 15:44, Harry Percival <harry.perci...@gmail.com> wrote:

> Thanks Tim, let me make sure I understand the current functionality:
>
> - django.request is the logger for views (broadly speaking)  any logging
> "elsewhere" would go to logger "django" instead.
> - django.request is set to propagate=False
>
> - if DEBUG is False, an exception in a view would go to mail_admins, but
> *not* to the console, because propagate=False
> - if DEBUG is False a logging.info outside of django.request would end up
> going nowhere anyway, because the console handler has require_debug_true
>
> - if DEBUG is True, an exception in a view goes only into the rendered
> debug HTML message
> - if DEBUG is True, a logging.info in a view goes nowhere, because
> propagate=False (a quick test confirms this, but i may have done it wrong?)
> - if DEBUG is True, a logging.info outside of django.request would go to
> the console
>
> So I have two questions:
>
> 1/ what is the scope of django.request?  Am I right in thinking it's
> "pretty much everything you normally do with django" because it's "any code
> that's invoked while handling a wsgi request" - so, in normal use,
> everything in views.py, forms.py, models.py etc  the only obvious way i
> can think of not going through a request would be a management command?
>
> 2/ wouldn't it be better if, when DEBUG=True, more logging stuff ended up
> in the console?  logging for management commands going to stderr by default
> is great, but wouldn't it be cool if logging.info and logging.exception
> in a view also went to stderr?
>
> Happy to update the docs if i can get answers up to 1/ at least :)
>
>
> On 1 January 2014 20:46, Tim Graham <timogra...@gmail.com> wrote:
>
>> I believe tracebacks are handled by the 'django.request' logger, not the
>> 'django' logger.
>>
>> You may find the commit that 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, December 28, 2013 8:11:00 AM UTC-5, Harry Percival wrote:
>>
>>>  The docs say:
>>>
>>>
>>> *"All messages reaching the django catch-all logger when DEBUG
>>> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DEBUG> is
>>> True are sent to the console. They are simply discarded (sent to
>>> NullHandler) when DEBUG
>>> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DEBUG> is
>>> False."*
>>> https://docs.djangoproject.com/en/1.6/topics/logging/#
>>> django-s-default-logging-configuration
>>>
>>> From reading that, I would (naively?) expect to see tracebacks in the
>>> terminal I'm running manage.py runserver, if any of my views raise an
>>> exception for example. I don't see any, however.
>>>
>>> Is this because the exception *is* caught, in that it gets intercepted
>>> and turned into the nice django debug page?  Am i misinterpreting the
>>> docs?  If so, would it be worth adding a couple of words of clarification
>>> in case anyone else might misread it like me?  Assuming anyone is that
>>> silly?
>>>
>>> Of course, I would rather prefer it if exception tracebacks *did* go to
>>> the console by default, as well as to mail_admins and/or to a nice django
>>> debug page.  But maybe that's just me.
>>>
>>> hp
>>>
>>> PS minimal repro:
>>>
>>> django-admin.py startproject myproj
>>> python manage.py startapp myapp
>>>
>>>
>>>
>>> *urls.py:*
>>> from django.conf.urls import patterns, include, url
>>> urlpatterns = patterns('',
>>> # Examples:
>>> url(r'^$', 'myapp.views.home', name='home'),
>>> )
>>>
>>>
>>> *myapp/views.py:*
>>> def home(request):
>>> raise Exception('arg')
>>>
>>> PPS apologies for x-post from django-users
>>>
>>>  --
>>> You received this message because you are subscribed to a topic 

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

[Harry Percival]

Thanks Tim, let me make sure I understand the current functionality:

- django.request is the logger for views (broadly speaking)  any logging
"elsewhere" would go to logger "django" instead.
- django.request is set to propagate=False

- if DEBUG is False, an exception in a view would go to mail_admins, but
*not* to the console, because propagate=False
- if DEBUG is False a logging.info outside of django.request would end up
going nowhere anyway, because the console handler has require_debug_true

- if DEBUG is True, an exception in a view goes only into the rendered
debug HTML message
- if DEBUG is True, a logging.info in a view goes nowhere, because
propagate=False (a quick test confirms this, but i may have done it wrong?)
- if DEBUG is True, a logging.info outside of django.request would go to
the console

So I have two questions:

1/ what is the scope of django.request?  Am I right in thinking it's
"pretty much everything you normally do with django" because it's "any code
that's invoked while handling a wsgi request" - so, in normal use,
everything in views.py, forms.py, models.py etc  the only obvious way i
can think of not going through a request would be a management command?

2/ wouldn't it be better if, when DEBUG=True, more logging stuff ended up
in the console?  logging for management commands going to stderr by default
is great, but wouldn't it be cool if logging.info and logging.exception in
a view also went to stderr?

Happy to update the docs if i can get answers up to 1/ at least :)


On 1 January 2014 20:46, Tim Graham <timogra...@gmail.com> wrote:

> I believe tracebacks are handled by the 'django.request' logger, not the
> 'django' logger.
>
> You may find the commit that 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, December 28, 2013 8:11:00 AM UTC-5, Harry Percival wrote:
>
>>  The docs say:
>>
>>
>> *"All messages reaching the django catch-all logger when DEBUG
>> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DEBUG> is
>> True are sent to the console. They are simply discarded (sent to
>> NullHandler) when DEBUG
>> <https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DEBUG> is
>> False."*
>> https://docs.djangoproject.com/en/1.6/topics/logging/#
>> django-s-default-logging-configuration
>>
>> From reading that, I would (naively?) expect to see tracebacks in the
>> terminal I'm running manage.py runserver, if any of my views raise an
>> exception for example. I don't see any, however.
>>
>> Is this because the exception *is* caught, in that it gets intercepted
>> and turned into the nice django debug page?  Am i misinterpreting the
>> docs?  If so, would it be worth adding a couple of words of clarification
>> in case anyone else might misread it like me?  Assuming anyone is that
>> silly?
>>
>> Of course, I would rather prefer it if exception tracebacks *did* go to
>> the console by default, as well as to mail_admins and/or to a nice django
>> debug page.  But maybe that's just me.
>>
>> hp
>>
>> PS minimal repro:
>>
>> django-admin.py startproject myproj
>> python manage.py startapp myapp
>>
>>
>>
>> *urls.py:*
>> from django.conf.urls import patterns, include, url
>> urlpatterns = patterns('',
>> # Examples:
>> url(r'^$', 'myapp.views.home', name='home'),
>> )
>>
>>
>> *myapp/views.py:*
>> def home(request):
>> raise Exception('arg')
>>
>> PPS apologies for x-post from django-users
>>
>>  --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/django-users/tCw4bqw2tsI/unsubscribe.
>>  To unsubscribe from this group and all its topics, send an email to
>> django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>>
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-users/60d3c4c6-22f8-4de6-a376-6230c33ad0a9%
>> 40googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> --
>> Harry J.W. Percival
>> --
>

Re: LiveServerTestCase, and override_settings(DEBUG=True)

[Harry Percival]

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-Magee 
>  
> wrote: 
>
> > The upside - If you add MEDIA_ROOT='/media/' to settings.py, the problem 
> goes away, because it gives the media layer something to match against that 
> won't catch all files. 
>
> I hit that issue a month ago and filed 
> https://code.djangoproject.com/ticket/21451 — with pretty much the same 
> analysis. 
>
> -- 
> Aymeric. 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/476680f5-4af7-4fa3-98c3-077eb29d60c3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Harry Percival]

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 UTC+1, Xavier Ordoquy wrote:
>
> Hi,
>
> Le 21 oct. 2013 à 16:04, Tino de Bruijn  
> a écrit :
>
> Harry's use case is an interesting one -- his authentication is being done 
>> entirely by an external process, so there's no need for a password field. 
>> Yes, he could just have the password and last_login fields and not use it, 
>> but why should he need to carry around he extra weight when Django doesn't 
>> need it.
>>
>
> @Harry, just out of curiosity, may I ask how you *do* authenticate your 
> users?
>
>
> I can't speak for Harry but using the RemoteUserBackend you don't need the 
> password nor the last_login for Django.
> In my case Apache did the authentication through Kerberos.
> Django's documentation explains more there: 
> https://docs.djangoproject.com/en/dev/howto/auth-remote-user/
>
> Regards,
> Xavier,
> Linovia.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cfc893f6-0177-4e5d-ac30-1ca109e98971%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

LiveServerTestCase, and override_settings(DEBUG=True)

[Harry Percival]

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:

django-admin.py startproject myproj
cd myproj
vi tests.py

In tests.py:

from django.test import LiveServerTestCase
from selenium import webdriver
from django.test.utils import override_settings

@override_settings(DEBUG=True)
class MinimalTest(LiveServerTestCase):

def setUp(self):
self.browser = webdriver.Firefox()
self.browser.implicitly_wait(3)

def tearDown(self):
self.browser.quit()


def test_admin_site_is_there(self):
self.browser.get(self.live_server_url + '/admin')
self.assertIn('Django administration', 
self.browser.find_element_by_tag_name('body').text)

Change DEBUG=True to DEBUG=False and this passes.  But, as-is, you get:

  File "/tmp/myproj/test1.py", line 18, in test_admin_site_is_there
self.assertIn('Django administration', 
self.browser.find_element_by_tag_name('body').text)
AssertionError: 'Django administration' not found in 'Page not found 
(404)\nRequest Method: GET\nRequest URL: 
http://localhost:8081/admin\n"admin; does not exist\nYou\'re seeing this 
error because you have DEBUG = True in your Django settings file. Change 
that to False, and Django will display a standard 404 page.'

I'm just using the admin URL because it's one that is activated by 
default.  Normal URLs, eg a home page view, also return 404s.  What's going 
on?



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb0d8b58-ea5c-4d7a-9c2a-d302d4adc3ae%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Harry Percival]

Hi Russell, thanks for getting back to us. Here's our info:

Host: PythonAnywhere -- https://www.pythonanywhere.com
Flavor: uWSGI
Notes: Free, one-click Django setup. PythonAnywhere is a full cloud-based 
development environment, so as well as hosting your Django app, you can 
edit your code, run scripts, schedule tasks and manage your database, all 
through our browser-based tools. No need to install anything locally. No 
need to edit Apache / Nginx config files.
Lowest yearly payment: $0.00

Now, if you're updating the page, and you fancied having a new section, 
near the top say, called "Free Django Hosting", we'd be very happy to be 
listed under that ;-)  Otherwise, I guess we belong in "Django-Friendly Web 
Hosts"


If you fancied tidying up a few broken links, here are some I've found:

* Django Web Host Statistics
Both links - ("top 20 Most Popular Django Web Hosts") and ("Django Powered 
Sites")
are broken/retired. 

* Django-specific Web hosts
Slicehost -- now redirects to rackspace. Not Django-specific. Should be in 
VPS section.
UnicHost VPS -- not Django-specific, should be in VPS section
ServQC hosting -- not Django-specific, should be in VPS section
Kutoken -- 404
djangohosting.com.ua -- 404
10for10.com (Empowering Media) -- link spam site
highspeedrails.com -- 404
modulix.com -- 500
pythonicity.co.uk -- 404
www.thinkhost.com -- times out
Nail Technician Kit -- is actually about Nailcare. I see what you mean 
about spam!
Hosting on Demand -- Dead
PerfoHost -- holding page, other link 404s

* Django-friendly VPS/dedicated hosts
Bodhost - second link - http://www.bodhost.co.uk/dedicated-hosting.shtml -- 
404
FrameworkCloud -- 404
Perfohost -- as above, not apparently django hosting
Server Evolution -- 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 %-)


On Tue, Nov 27, 2012 at 10:57 PM, Harry Percival 
<harry.p...@gmail.com> 
wrote:

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 plan, so it's a nice place for people to 
come and try out Django, for free, maybe host a prototype web app...

I'd be very happy help out more generally, by, say, cleaning up that page, 
fixing/removing broken links (I found a few), etc...

I'd need WIKI_ADMIN privileges on the trac instance. my username is hjwp.

rgds,
Harry



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/h6XZT7_QucIJ.
To post to this group, send email to django-d...@googlegroups.com
.
To unsubscribe from this group, send email to 
django-develop...@googlegroups.com .
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ZfhoSmoyljQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[Harry Percival]

Hey,

We're definitely committed to the freemium model, so there should always be 
a free plan + free web hosting.  What we might do is tweak the bandwidth 
and cpu usage restrictions to encourage heavy users to start paying, but 
people running a small webapp shouldn't have anything to worry about.

I should also say that it's our intention to grandfather in any feature 
changes for the free accounts in future.  So if, for example, we decided 
(say) that HTTPS was going to become a paid-for feature, we'd still keep it 
free for any users that had already signed up, they could still keep using 
HTTPS on their free web apps - it would only be new free accounts that 
would be HTTP-only...

Hope that helps?

cheers,
HP

On Thursday, November 29, 2012 1:20:14 PM UTC, is_null wrote:
>
> I've set up the test_project of one of my apps - 
> http://jpic.pythonanywhere.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
>
>
> On Tue, Nov 27, 2012 at 3:57 PM, Harry Percival 
> <harry.p...@gmail.com
> > wrote:
>
>> 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 plan, so it's a nice place for people to 
>> come and try out Django, for free, maybe host a prototype web app...
>>
>> I'd be very happy help out more generally, by, say, cleaning up that 
>> page, fixing/removing broken links (I found a few), etc...
>>
>> I'd need WIKI_ADMIN privileges on the trac instance. my username is hjwp.
>>
>> rgds,
>> Harry
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-developers/-/h6XZT7_QucIJ.
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
>
> -- 
> http://yourlabs.org <http://blog.yourlabs.org>
> Customer is king - Le client est roi - El cliente es rey.
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0MOXd1KXI1kJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

I'd like to make a contribution to the wiki

[Harry Percival]

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 plan, so it's a nice place for people to 
come and try out Django, for free, maybe host a prototype web app...

I'd be very happy help out more generally, by, say, cleaning up that page, 
fixing/removing broken links (I found a few), etc...

I'd need WIKI_ADMIN privileges on the trac instance. my username is hjwp.

rgds,
Harry

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/h6XZT7_QucIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.