Re: Exceptions caught by the "include" template tag make it hard to rely on tests

[Sylvain Fankhauser]

Hi,

I'm bringing this back to the table since I can't believe I'm the only one
to find this behaviour weird and possibly dangerous. I'd really be
interested in getting your opinion on this!

Thanks,
Sylvain

2016-06-09 14:37 GMT+02:00 Sylvain Fankhauser 
:

> Hi all,
>
> I got really frustrated today trying to understand why a bug could get
> past my test suite but fail in my dev environment. Finally Baptiste
> Mispelon pointed me to the include template tag documentation
> <https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#include>:
>
> If the included template causes an exception while it’s rendered
>> (including if it’s missing or has syntax errors), the behavior varies
>> depending on the template engine's debug option (if not set, this option
>> defaults to the value of DEBUG). When debug mode is turned on, an exception
>> like TemplateDoesNotExist or TemplateSyntaxError will be raised. When debug
>> mode is turned off, {% include %} logs a warning to the django.template
>> logger with the exception that happens while rendering the included
>> template and returns an empty string.
>>
>
> That's a real problem when running tests, because since the exception is
> just silenced your tests will still pass although there was actually some
> error in your code. The current way to deal with this is, I guess, to set
> the template engine DEBUG option to True in the test environment but that
> doesn't seem right to me.
>
> I don't have a solution right now and I know this would be a big backwards
> incompatible change and the chances for this to change are abysmally low.
> But maybe we could just add an option for that (to make exceptions pop out
> of the include tag), set its default value to match the current behaviour,
> and change it with a clear deprecation plan?
>
> Cheers,
> Sylvain
>

-- 
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/CAAXOc44qh%2B6iNkh5B6C_oYEo2dks-MQUi19SmZHJA6X_BJZh2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Exceptions caught by the "include" template tag make it hard to rely on tests

[Sylvain Fankhauser]

Hi all,

I got really frustrated today trying to understand why a bug could get past
my test suite but fail in my dev environment. Finally Baptiste Mispelon
pointed me to the include template tag documentation
:

If the included template causes an exception while it’s rendered (including
> if it’s missing or has syntax errors), the behavior varies depending on the
> template engine's debug option (if not set, this option defaults to the
> value of DEBUG). When debug mode is turned on, an exception like
> TemplateDoesNotExist or TemplateSyntaxError will be raised. When debug mode
> is turned off, {% include %} logs a warning to the django.template logger
> with the exception that happens while rendering the included template and
> returns an empty string.
>

That's a real problem when running tests, because since the exception is
just silenced your tests will still pass although there was actually some
error in your code. The current way to deal with this is, I guess, to set
the template engine DEBUG option to True in the test environment but that
doesn't seem right to me.

I don't have a solution right now and I know this would be a big backwards
incompatible change and the chances for this to change are abysmally low.
But maybe we could just add an option for that (to make exceptions pop out
of the include tag), set its default value to match the current behaviour,
and change it with a clear deprecation plan?

Cheers,
Sylvain

-- 
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/CAAXOc46M7jbPtF2rBZsOjod-Wm%2BatCtbpuTaFE%2BFgxhc4gSqCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[Sylvain Fankhauser]

The only problem I can see is dependencies conflicts, where Django would
need package X version > 1.0 and another installed package would need
package X version 0.9. I have this issue with a project of mine that
required six >= 1.10 and for some reason Xcode on OSX with the system
Python (ie. not installed with brew for example) forces you to have six
1.9, which comes before in the PYTHONPATH. I know that Lektor
 for example solves this by having an install
script  that creates a virtualenv and
installs it inside this virtualenv. Also James mentioned that "back in the
days pip wasn't as awesome as it is today", but we have to keep in mind
that a lot of OSes still use an old pip version by default (Debian stable
for example ships pip 1.5
).


Anyway as long as Django is installed in a virtualenv this shouldn't be too
much of an issue, but I think we should expect some issues from the users
and these should be documented otherwise people might get frustrated.

Cheers,
Sylvain
On Apr 6, 2016 13:43, "Marc Tamlyn"  wrote:

> Does anyone (potentially from OS packaging worlds maybe) have a good
> reason NOT to have a dependency?
>
> In the event that Django does have Pip dependencies, I still think we
> should establish some rules. Things like they should be stable and mature,
> and perhaps widely known, and still be under active maintenance. These are
> all hazy ideas of course, but I think adding any new dependency should be
> something which we are cautious of, not something we do without careful
> consideration.
>
> If someone can put together some documentation or a DEP for how this
> process would work, I think this is a matter significant enough to talk
> about properly, and in a thread more clearly named. Such a proposal should
> also ideally reference what we do or have vendored before, why, and how
> well of otherwise that process has worked.
>
> Marc
> On 5 Apr 2016 9:49 a.m., "James Pic"  wrote:
>
>> Adding dependencies would definitely be a huge step forward. I think
>> Django doesn't have them because pip wasn't as awesome as it is today
>> back in the early days, but nowadays it would definitely make sense.
>> That would mean a bit more work for distribution package maintainers
>> but if we can start communicating with them about it then would there
>> be any reason not to do this move ?
>>
>> --
>> 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/CALC3Kae1Mt5LzYRq0PQbQcEMKwvbK%2Begr4FuC6baB5NZZtSbtA%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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1HqgJ%3DM93yWgmatZtc4s8%3DRB8FFfga24aJ3X_D_Ey2xdw%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAXOc44oMGNo38_CNw%2BnEKFEK_NWXPSPG8b0%2B1YKq%2Bi08ARMng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Feedback on improving GeoDjango docs

[Sylvain Fankhauser]

Hello,

I'm currently working on ticket #22274
, which is an effort to
improve the GeoDjango documentation to make it more accessible to
newcomers. This represents quite some work and I'm still in the early
stages but I'd love to have some feedback on the general structure I'm
planning to create. You can find the current status of the potential new
docs here: http://sephii.github.io/django-22274/ref/contrib/gis/index.html
(current version of the docs can be found here
https://docs.djangoproject.com/en/1.9/ref/contrib/gis/).

The tutorial part is not yet representative of what I'm planning to do so
no need to check that yet. That said, I found it quite difficult to come up
with a tutorial topic that would allow me to get through most of the
features from GeoDjango. So if you have an idea for a usecase I could use
for the tutorial, this would be more than welcome.

Some other things I have on my todo list are:

* Clarify installation instructions, split the platform-specific
instructions into separate documents
* Check if we can try to merge together some parts in the "Models" section
(ie. GeoDjango Database API, Geographic Database Functions and GeoQuerySet
API Reference), which all serve the same purpose

If you see anything else, feel free to comment.

Cheers,
Sylvain

-- 
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/CAAXOc44Kp8JVpEZ9zgUAw-aFdT30MdtjodAb7R4SzY2PB7LYsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

geodjango.org status

[Sylvain Fankhauser]

Hello,

I'm working on issue #22274 
and as part of this ticket I stumbled upon the domain geodjango.org
website. I don't think this adds any value to GeoDjango, and in fact this
is more a risk to confuse users by having an external website for a feature
that's part of Django. Also the Twitter account
 linked by this website doesn't really seem
active, not to mention the last tweet that's a bit weird.

My proposal would be to keep the current domain and make it redirect to the
official GeoDjango docs, and add a link to the mailing list in the official
docs in a "Getting help" box, just like it's done in the Django docs.

What do you people think?

Cheers,
Sylvain

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