Re: Sonar for the Django rpoject

[Ivan Sevastoyanov]

Hi,

I'm on a vacation and far from my PC now so it's possible that I'll not be 
able to answer some of the questions.
@Sergei - Sonar can be applied the same way you have Jenkins. It will be 
easier to track some issues immediately. Sonar combines all the rules from 
pylint, pep8 plus some other rules. It's just more convenient.

Regards,
Ivan

On Sunday, September 4, 2016 at 2:38:06 AM UTC+3, Sergei Maertens wrote:
>
> I kind of like these reports, since they can take away some of the early 
> review work. I would put it on the same level as the `isort` checks we have 
> now. On the other hand, adapting the existing codebase to 'resolve' this 
> code smells will introduce quite some 'stupid' commits, so it might be best 
> to get it done with in one or two go's.
>
> If it can be applied to pull-requests, it would be nice I guess.
>
> One final question: why use sonar instead of something like pylint/pep8 - 
> these tools also provide static analysis and report common violations in 
> the Python world.
>
> On Wednesday, August 31, 2016 at 7:50:38 PM UTC+2, Ivan Sevastoyanov wrote:
>>
>>
>> 
>> I'm posting the the 11 criticals. In my opinion, they are not critical, 
>> they are just code smells. I will try to export the report so you can 
>> review the major issues by groups.
>>
>> Regards,
>> Ivan
>>
>> On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote:
>>>
>>> Any security issues should be reported to secu...@djangoproject.com, 
>>> otherwise it's fine to share the information here.
>>>
>>> On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov 
>>> wrote:

 All the rules are with a default severity so there might be some major 
 issues that it's worth reviewing them. I will post the critical issues 
 this 
 evening because I'm at work now. Do you want to post them somewhere else 
 because it's a sensitive information? I will try to find out how to export 
 the whole report in a convenient format.

 Regards,
 Ivan

 On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham wrote:
>
> Perhaps you could tell us about some of the critical issues so we 
> could get a sense for that.
>
> On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov 
> wrote:
>>
>>
>> 
>> That is the report from the Sonar with all the rules included. 
>> Unfortunately, I cannot export it as a PDF or some more convenient 
>> format. 
>> I can describe all the steps in my blog so some of the Django members 
>> could 
>> set up Sonar on his/her machine and see a lot more details and figure 
>> out 
>> if it's worth it to fix some of the issues.
>>
>> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin 
>> wrote:
>>>
>>> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov  
>>> wrote: 
>>>
>>> > My question is do you consider using SonarQube for code quality 
>>> analysis, static analysis and find bugs because it's able to do that. 
>>>
>>>
>>> I guess that depends on the signal / noise ratio in the things 
>>> SonarQube flags. 
>>>
>>> Perhaps you could do an initial run and see whether SonarQube spots 
>>> interesting bugs? 
>>>
>>> I have no idea what the results could be because I’m not familiar 
>>> with static analysis of Python code. 
>>>
>>> -- 
>>> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a05e529f-4d38-42c0-bf11-edf8107ea45a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sergei Maertens]

No, this is actually one of the reasons I keep recommending people to use 
inclusion tags as opposed to the {% include %} tag, and I see the same 
recommendation/reasoning in the IRC channel.

On Tuesday, July 12, 2016 at 12:36:11 AM UTC+2, Tim Graham wrote:
>
> Has anyone relied on the exception silencing behavior as a "feature" when 
> using {% include %}? It doesn't seem that's really possible given you can't 
> use that feature when template.debug=True. Thus, the current behavior 
> doesn't strike me as a reasonable default. Perhaps we can change it after a 
> deprecation. Does anyone really want an alternative to keep the silencing 
> behavior?
>
> From a user's perspective, I think it's more confusing to see a partial 
> and possibly broken page (but not necessarily knowing that it's broken) 
> than an error page.
>
> On Monday, July 11, 2016 at 6:17:58 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 11 July 2016 22:45:31 Florian Apolloner wrote: 
>> > On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote: 
>> > > As for me as a developer, I'd support removing the exception 
>> silencing 
>> > > that {% include %} does so that errors appear alongside any other 
>> > > exceptions (e.g. in Sentry) rather than in the django.template logger 
>> > > (that logging was added in Django 1.9). 
>> > 
>> > Dito, most tags should error out where it makes sense, but not sure if 
>> we 
>> > can easily change that :( 
>>
>> It must be opt-in; now that we have template engines and they're 
>> configured in 
>> dictionaries, we have plenty of room for that, though. 
>>
>> Another option to consider is make them error out only under the 
>> test-client. 
>>
>> My 2 cents, 
>> Shai. 
>>
>

-- 
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/15102754-c381-45ea-9b57-61b31c6e791f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Curtis Maloney]

If there will be sweeping commits to remove six and other py2 concessions, can 
the cleaning be included then?

On 4 September 2016 9:38:05 AM AEST, Sergei Maertens  
wrote:
>I kind of like these reports, since they can take away some of the
>early 
>review work. I would put it on the same level as the `isort` checks we
>have 
>now. On the other hand, adapting the existing codebase to 'resolve'
>this 
>code smells will introduce quite some 'stupid' commits, so it might be
>best 
>to get it done with in one or two go's.
>
>If it can be applied to pull-requests, it would be nice I guess.
>
>One final question: why use sonar instead of something like pylint/pep8
>- 
>these tools also provide static analysis and report common violations
>in 
>the Python world.
>
>On Wednesday, August 31, 2016 at 7:50:38 PM UTC+2, Ivan Sevastoyanov
>wrote:
>>
>>
>>
>
>> I'm posting the the 11 criticals. In my opinion, they are not
>critical, 
>> they are just code smells. I will try to export the report so you can
>
>> review the major issues by groups.
>>
>> Regards,
>> Ivan
>>
>> On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote:
>>>
>>> Any security issues should be reported to secu...@djangoproject.com,
>
>>> otherwise it's fine to share the information here.
>>>
>>> On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov
>
>>> wrote:

 All the rules are with a default severity so there might be some
>major 
 issues that it's worth reviewing them. I will post the critical
>issues this 
 evening because I'm at work now. Do you want to post them somewhere
>else 
 because it's a sensitive information? I will try to find out how to
>export 
 the whole report in a convenient format.

 Regards,
 Ivan

 On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham
>wrote:
>
> Perhaps you could tell us about some of the critical issues so we
>could 
> get a sense for that.
>
> On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov
>
> wrote:
>>
>>
>>
>
>> That is the report from the Sonar with all the rules included. 
>> Unfortunately, I cannot export it as a PDF or some more
>convenient format. 
>> I can describe all the steps in my blog so some of the Django
>members could 
>> set up Sonar on his/her machine and see a lot more details and
>figure out 
>> if it's worth it to fix some of the issues.
>>
>> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin
>
>> wrote:
>>>
>>> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov
> 
>>> wrote: 
>>>
>>> > My question is do you consider using SonarQube for code
>quality 
>>> analysis, static analysis and find bugs because it's able to do
>that. 
>>>
>>>
>>> I guess that depends on the signal / noise ratio in the things 
>>> SonarQube flags. 
>>>
>>> Perhaps you could do an initial run and see whether SonarQube
>spots 
>>> interesting bugs? 
>>>
>>> I have no idea what the results could be because I’m not
>familiar 
>>> with static analysis of Python code. 
>>>
>>> -- 
>>> 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 https://groups.google.com/group/django-developers.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/21d19365-ab7f-4870-9140-e8ec2f786b87%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/5DB3699E-959B-40C9-852C-5A9CB41DA436%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Sergei Maertens]

I kind of like these reports, since they can take away some of the early 
review work. I would put it on the same level as the `isort` checks we have 
now. On the other hand, adapting the existing codebase to 'resolve' this 
code smells will introduce quite some 'stupid' commits, so it might be best 
to get it done with in one or two go's.

If it can be applied to pull-requests, it would be nice I guess.

One final question: why use sonar instead of something like pylint/pep8 - 
these tools also provide static analysis and report common violations in 
the Python world.

On Wednesday, August 31, 2016 at 7:50:38 PM UTC+2, Ivan Sevastoyanov wrote:
>
>
> 
> I'm posting the the 11 criticals. In my opinion, they are not critical, 
> they are just code smells. I will try to export the report so you can 
> review the major issues by groups.
>
> Regards,
> Ivan
>
> On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote:
>>
>> Any security issues should be reported to secu...@djangoproject.com, 
>> otherwise it's fine to share the information here.
>>
>> On Wednesday, August 31, 2016 at 2:25:55 AM UTC-4, Ivan Sevastoyanov 
>> wrote:
>>>
>>> All the rules are with a default severity so there might be some major 
>>> issues that it's worth reviewing them. I will post the critical issues this 
>>> evening because I'm at work now. Do you want to post them somewhere else 
>>> because it's a sensitive information? I will try to find out how to export 
>>> the whole report in a convenient format.
>>>
>>> Regards,
>>> Ivan
>>>
>>> On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham wrote:

 Perhaps you could tell us about some of the critical issues so we could 
 get a sense for that.

 On Tuesday, August 30, 2016 at 4:26:42 PM UTC-4, Ivan Sevastoyanov 
 wrote:
>
>
> 
> That is the report from the Sonar with all the rules included. 
> Unfortunately, I cannot export it as a PDF or some more convenient 
> format. 
> I can describe all the steps in my blog so some of the Django members 
> could 
> set up Sonar on his/her machine and see a lot more details and figure out 
> if it's worth it to fix some of the issues.
>
> On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin 
> wrote:
>>
>> On 28 Aug 2016, at 21:43, Ivan Sevastoyanov  
>> wrote: 
>>
>> > My question is do you consider using SonarQube for code quality 
>> analysis, static analysis and find bugs because it's able to do that. 
>>
>>
>> I guess that depends on the signal / noise ratio in the things 
>> SonarQube flags. 
>>
>> Perhaps you could do an initial run and see whether SonarQube spots 
>> interesting bugs? 
>>
>> I have no idea what the results could be because I’m not familiar 
>> with static analysis of Python code. 
>>
>> -- 
>> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/21d19365-ab7f-4870-9140-e8ec2f786b87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - September 3, 2016

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/27147 - Add support for defining 
bounds in postgres range fields (accepted)

https://code.djangoproject.com/ticket/27148 - Invalid input for UUIDField 
with ModelMultipleChoiceField throws ValueError, not ValidationError 
(accepted)

https://code.djangoproject.com/ticket/27150 - Document that a name should 
be provided when wrapping file-like objects that don't have one with File 
(accepted)

https://code.djangoproject.com/ticket/27146 - template shows empty string 
instead of actual content when it contains characters like \x93 and \x94 
(needsinfo)

https://code.djangoproject.com/ticket/27160 - Document that running the 
Django test suite requires creating the databases and, on PostgresQL, a 
superuser (accepted)

https://code.djangoproject.com/ticket/27151 - FK index created two times on 
PostgreSQL if referenced table PK is varchar (accepted)

https://code.djangoproject.com/ticket/27157 - AdminForm may crash if 
model_admin argument is None (accepted)

https://code.djangoproject.com/ticket/27161 - TypedChoiceField fails to 
validate properly when used with ArrayField (accepted)

https://code.djangoproject.com/ticket/27164 - Database routers examples 
could be more realistic (accepted)

https://code.djangoproject.com/ticket/27149 - Allow using a subquery in 
QuerySet.filter() (accepted)

Authored



https://github.com/django/django/pull/7177 - Fixed #27140 -- Prevented 
template rendering from hiding a property's TypeError.

https://github.com/django/django/pull/7194 - Fixed #27142, #27110 -- Made 
makemigrations consistency checks respect database routers.

https://github.com/django/django/pull/5382 - Fixed #24865 -- Added 
remove_stale_contenttypes management command.

Reviewed/committed

--

https://github.com/django/django/pull/7168 - Fixed #27132 -- Allowed 
testing MemcachedCache and PyLibMCCache during the same test run.

https://github.com/django/django/pull/7165 - Fixed #27153 -- Added 
validation for HttpResponse status.

https://github.com/django/django/pull/7190 - Fixed #27154 -- Allowed 
comparing CallableBool with bitwise or.

https://github.com/django/django/pull/7160 - Fixed #20892 -- Allowed 
configuring memcached client using OPTIONS.

https://github.com/django/django/pull/7191 - Fixed #27152 -- Supported 
comma delimiter in memcached LOCATION string.

https://github.com/django/django/pull/7079 - Fixed #24112 -- Fixed 
assertInHTML()'s counting if needle has no root element.

https://github.com/django/django/pull/7195 - Refs #27039 -- Fixed 
regression with field defaults in prefixed forms.

https://github.com/django/django/pull/6877 - Fixed #5908 -- Added {% 
resetcycle %} template tag.

https://github.com/django/django/pull/7198 - Refs #25850 -- Documented 
migration history consistency checks.

https://github.com/django/django/pull/7200 - Fixed #11331 -- Stopped 
closing pylibmc connections after each request.

https://github.com/django/django/pull/7154 - Fixed #27108 -- Displayed 
collectstatic's delete/overwrite warnings only if some files exist in 
STATIC_ROOT.

https://github.com/django/django/pull/7106 - Fixed #25476 -- Allowed 
PostgreSQL introspection to work regardless of table owner.

https://github.com/django/django/pull/6954 - Fixed #27097 -- Added index 
type introspection to built-in db backends.

https://github.com/django/django/pull/6954 - Fixed #25788 -- Enabled the 
cached template loader if debug is False.

https://github.com/django/django/pull/7056 - Fixed #26098 -- Used 
cdnjs.cloudflare for OpenLayers.js.

https://github.com/django/django/pull/7201 - Fixed #27171 -- Added 
unicode_literals and coding preamble to all files in startapp template on 
Python 2.

Reviews of core dev work



https://github.com/django/django/pull/7178 - Fixed #27131 -- Passed proper 
string type to SMTP connection login

https://github.com/django/django/pull/7171 - Fixed #25109 -- Stopped 
silencing explicitly specified migration modules import errors.
https://github.com/django/django/pull/7134 - Fixed #25181 -- Added 
localdate() function to get date in a different time zone.

-- 
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/0a8a4878-878f-4a7f-a3e2-bdf7e0f21eb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.