Re: Testing Django using Docker

[Enrique Paredes]

There's one good basic example of docker-compose in pydanny's cookiecutter 
django package, if you need it.



—
Sent from Mailbox

On Mon, Nov 9, 2015 at 9:04 AM, Jani Tiainen  wrote:

> Hi,
> I think you should document this in Wiki at least.
> Few additional questions notes:
> What's the Docker overhead? (starup/shutdown time)
> Could waiting for db container be more robust? Now it's just "random 
> number".
> Using docker-compose would be nice to avoid problems with container 
> startup times.
> On 07.11.2015 14:46, Andreas Madsack wrote:
>> Hello,
>>
>> I did a first version of a Dockerfile for testing using Docker with a 
>> Postgresql Docker container.
>> see https://github.com/mfa/django-runtests-docker
>>
>> The readme contains a walkthrough for a fresh digitialocean box (you 
>> need 1GB RAM! 512MB and a swap file also works).
>> On a linux host you can run the testsuite with "sh run.sh".
>>
>> Should this way of running the tests be integrated in the docs?
>> And should the Dockerfile and the runscript be in the django tests folder?
>>
>> Regards,
>> Andreas
>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/5f4750dd-36c6-4d80-b222-6d203ada2974%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/56405370.8060100%40gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1447064529975.9bd091b8%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: Why leave explicit null=True when blank is True in IntegerField, DateField etc?

[Enrique Paredes]

Well, one can call the Zen of python, about just exactly that. explicit is 
better than implicit.


In this case, explicit becomes a problem for getting used to it, versus 
implicit that becomes a strange behavior/bug/wtf when you don't expect it.




I'll rather see a ValueError if this is something the model field can't afford 
(Doesn't do it already?)




Cheers,

E.





—
Sent from Mailbox

On Thu, Sep 17, 2015 at 12:36 AM, Paulo Maciel 
wrote:

> It would be better if IntegerField, DateField, etc did not have to leave 
> explicit null=True when blank is True. 
> In my opinion it might look like:
> class Abc(models.Model):
> number = models.IntegerField(blank=True)  # doesn't need leave explicit 
> null=True, it's should be default if blank is True
> What do you think?
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7ced3a69-fd04-4ac9-9334-8fde61726810%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1442460232075.4cd4456e%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support a javascript template language on the server

[Enrique Paredes]

IMHO, this can be easily solved with nunjucks.js and jinja which are both 
interchangeable, but in my experience it's better to had 2 template languages. 
Using only one tpl gives you the need to implement the same in the django views 
than in the js controller wich is "harsh" coupled and a PITA.


Also the need to reimplement django.shortcuts.render is unneded. Add in the 
base tpl a {% if request.is_ajax %} then wrap the result in a entire html tpl 
for regular http calls and the new content only in the other case.




Another option is to use django_braces and AjaxResponseView to respond back 
ajax with only json data but again you'll be force to sync django views and the 
controller for js.




Just my two cents, I'm used to build JS intense sites backed with django 
without any problem.




For me the work should be documenting how to use django with a client MV# and 
list the options and the apis for that.




Cheers!

E.

On Sat, May 30, 2015 at 6:52 PM, Emil Stenström  wrote:

> Hi,
> This is the second feature proposal as part of my general drive for 
> getting Django to work better for javascript heavy sites.
> Support a javascript template language on the server
> 
> The multiple template engine work has made it possible to switch out 
> Django Templates with another engine. One of the most powerful things 
> this enables is to use a template language that is executable both on 
> the server and client.
> A typical use-case for this could be that you have a list of tweets on 
> your site. When the user first loads the page you send the full HTML for 
> all the rendered tweets over. When there's a new tweet you would like to 
> just add that one tweet to the list, without re-rendering the whole 
> page. Now you have a couple of options:
> 1. Reimplement the Django template code from your site in javascript. 
> This is harder the more complex the template your have. Also risks bugs 
> when you change the server-side template but forget the client-side one.
> 2. Use Pjax, render everything on the server and send the result to the 
> page. This sends unnecessary data over the wire, and requires that you 
> figure out how to append the data in the correct location.
> 3. Send the server-side templates to the browser, and then re-render on 
> the client when new data arrives. This uses the least data over the 
> wire, and does not require that you keep track of mappings, just update 
> the data and re-render everything (React.js's virtual DOM can make this 
> really fast if you need it to be).
> Option 3 opens up lots of interesting use-cases for Django, that 
> previously was only possible for javascript-based frameworks.
> ---
> To be clear, I'm not saying that Django should include any front-end 
> code at all. That's something that the individual developer should have 
> full control over. But what needs to happen is that the same templates 
> that Django uses needs to be accessible to, and executable in, javascript.
> For this to work, two things needs to be built:
> 1. A way to access the template and the template context for a view 
> separately, so that it can be delivered to the client. Maybe the easiest 
> would be to modify django.shortcuts.render so it returns both the input 
> and the result. The client could then get access to this via a 

Re: Guessable entry points

[Enrique Paredes]

So along this line of thought,  `django-admin` is a good command name? 





To me the admin, in the django world is a clear distint concept to what this 
command does.




Besides to be used to it, seems more natural to call it `django`. 




Cheers,

E.

On Fri, May 1, 2015 at 2:33 PM, Michael Manfre  wrote:

> I like the alias.
> On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>> `python -m django` as a alias for `django-admin` sounds good.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 30 avr. 2015, at 19:15, Ryan Hiebert  wrote:
>>
>> https://github.com/django/django/pull/4588
>>
>> I this PR I suggest to add a `django` entry point that is identical to
>> `django-admin`, and a `__main__.py` that also is a mirror of `django-admin`.
>>
>> There’s also related discussion at
>> https://github.com/django/django/pull/3861
>>
>> There’s precedent for using these as the primary methods of use all over
>> the place. Flask, in particular, uses both the `flask` command as well as
>> `python -m flask`. Celery also uses the `celery` command as well as `python
>> -m celery`.
>>
>>
>> I see value in adding these endpoints that are more easily guessable.
>> However, there’s a cost too, the cost of having more than one way to do it.
>> We already have `django-admin` and `django-admin.py`, would adding these
>> obvious entry points give too many options?
>>
>> Ryan
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/90DC7B87-35F5-4B77-93EA-7734DA31EA86%40ryanhiebert.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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/37733725-6295-48F4-98D1-BC82978EE570%40polytechnique.org
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAGdCwBtZbmwE1hU-5knGR-OPO23Y35wZ5cV2ygDOK7aaPTUt1w%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1430488299401.034ca1d9%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: Drop the TEMPLATE_DEBUG setting

[Enrique Paredes]

+1

Last year I do an app to develop templates on the fly granting template_debug 
dump to some users (designers) and even in that escenario is looking good. Go 
for it.

On Sun, Feb 15, 2015 at 4:42 PM, Marc Tamlyn 
wrote:

> +1 to removing it
> On 15 Feb 2015 14:16, "Aymeric Augustin" 
> wrote:
>> Hello,
>>
>> During the multiple template engines refactor, I didn’t touch
>> TEMPLATE_DEBUG.
>> The only purpose of this setting is to control whether Django stores the
>> information required to display stack traces for exceptions that occur
>> while
>> rendering Django templatse. I think I should have deprecated it for the
>> following reasons.
>>
>> 1) Having the debug option of Django template engines default to DEBUG
>> instead
>> of TEMPLATE_DEBUG will allow everyone to remove TEMPLATE_DEBUG = DEBUG from
>> their settings.
>>
>> 2) For the uncommon situation where one needs TEMPLATE_DEBUG != DEBUG, the
>> new
>> TEMPLATES settings provides a solution:
>>
>> TEMPLATES = [
>> {
>> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
>> 'OPTIONS': {
>> 'debug': True,
>> },
>> },
>> ]
>>
>> There should be only one way to do it and TEMPLATES beats TEMPLATE_DEBUG.
>>
>> 3) That will save developers of third-party backends from thinking about
>> the
>> semantics of TEMPLATE_DEBUG vs. DEBUG. At best it's a pointless exercise
>> and
>> at worst it will introduce inconsistencies. For example the maintainer of
>> django-jinja is about to diverge from Django in this regard:
>> https://github.com/niwibe/django-jinja/issues/87
>>
>> I would like to update the DEP and make this change in Django 1.8 beta.
>>
>> What do you think?
>>
>> --
>> Aymeric.
>>
>>
>>  --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/45CFE41A-16D5-4A6B-AF27-505C3E4BEA75%40polytechnique.org
>> 
>> .
>> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMwjO1EaJQpsj4qitLyf0Ah77Fs_8_yFpbdJn%3DV8JwphUEvt4g%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1424026778601.9b6b2e23%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.