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.

Re: Add documentation to address OWASP Top 10?

[Tim Graham]

Proposed text:

Take a look at the Open Web Application Security Project (OWASP) Top 10 list 
 which identifies some 
common vulnerabilities in web applications. While Django has tools to 
address some of the issues, other issues must be accounted for in the 
design of your project.

(linked to https://www.owasp.org/index.php/Top_10_2013-Top_10)

https://github.com/django/django/pull/6425

On Wednesday, April 6, 2016 at 5:03:24 AM UTC-4, Erik Cederstrand wrote:
>
>
> > Den 6. apr. 2016 kl. 07.29 skrev Anssi Kääriäinen  >: 
> > 
> > It is notable that if the number of items is a secret (say, you don't 
> > want to reveal how many sales items you have), just having information 
> > about sequential numbers is bad. In that case you should use UUID, 
> > which the documentation could point out. 
>
> If anything about your data is sensitive, then there are a pile of side 
> channels that putting your data online could expose. URLs are just one. For 
> an entertaining read, google "German tank problem". 
>
> Giving specific security advice in the documentation that doesn't strictly 
> refer to Django features could IMO lead to the false expectation that 
> you're magically secure if you follow the advice. I would prefer that the 
> documentation simply pointed to further reading, e.g. OWASP. 
>
> Erik

-- 
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/17a7595b-821b-4ab2-95c8-3bc54b7650d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: must we include the source files for all minified JavaScript?

[Carl Meyer]

It seems like a reasonable request to me. It's just generally useful to
have the original source matching the minified code available, e.g. for
debugging an issue with that code. In theory you can go find the
corresponding non-minified code yourself, but it's not always easy to
find exactly the right corresponding version, and there's not much
reason to make that work necessary.

Carl

On 04/06/2016 10:58 AM, Tim Graham wrote:
> From a Trac ticket [0]:
> 
> 
> In Debian, we like to have the sources of everything that we ship and we
> consider that minified javascript files are not really scripts (which
> are their own source).
> 
> There are currently two problematic files in Django:
> 
> 
> js_tests/qunit/blanket.min.js
> django/contrib/admin/static/admin/js/vendor/xregexp/xregexp.min.js
> 
> 
> To remedy this I would suggest to either:
> 
>   * directly use a non-minified file like you do for many other
> javascript files (ex:
> django/contrib/admin/static/admin/js/SelectFilter2.js)
>   * store a non-minified file next to the minified file (same name
> without the ".min" part) 
> 
> [0] https://code.djangoproject.com/ticket/26474
> 
> -- 
> 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/acca9df5-2377-4e6c-b103-6167c9e4bd87%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57054173.4040307%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

must we include the source files for all minified JavaScript?

[Tim Graham]

>From a Trac ticket [0]:


In Debian, we like to have the sources of everything that we ship and we 
consider that minified javascript files are not really scripts (which are 
their own source).

There are currently two problematic files in Django:


js_tests/qunit/blanket.min.js
django/contrib/admin/static/admin/js/vendor/xregexp/xregexp.min.js


To remedy this I would suggest to either:

   - directly use a non-minified file like you do for many other javascript 
   files (ex: django/contrib/admin/static/admin/js/SelectFilter2.js) 
   - store a non-minified file next to the minified file (same name without 
   the ".min" part) 

[0] https://code.djangoproject.com/ticket/26474

-- 
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/acca9df5-2377-4e6c-b103-6167c9e4bd87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird for django 1.8.x alpha

[gilberto dos santos alves]

hi. i will make some testes with firebird 2.0.5 and access to comercial
software lojafacil that use firebird. thanks for message.

2016-04-06 8:13 GMT-03:00 mariuz :

> The current master branch is being developed under django 1.8.x
>
> This is still in alpha status but I think the base code works pretty well.
>
> Any feedback wiil be appreciated.
>
>
> https://github.com/maxirobaina/django-firebird/commits/master
>
> --
> 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/dcfb44eb-8dd0-49b0-817e-4576097e5d32%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

-- 
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/CAP9G-N%2BMr-t_4eeg54C1XK9eB5mJbo-dx%2Bjey24xtnS%2B0tV5KQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Johannes Hoppe]

I understand that. Select2 used to be horrible before the version 4 release.
Selectize was on the table, but dropped because it doesn't allow 
configuration via `data`-attriburtes. We wanted to keep the JS party as 
minial as possible.
Select2 does a good job since version 4, you can configure everything via 
data attributes.

On Wednesday, April 6, 2016 at 4:25:23 PM UTC+2, Andrew Ingram wrote:
>
> In previous projects (before moving to rolling my own UI components), I 
> ended up favouring Selectize (http://selectize.github.io/selectize.js/) 
> after getting fed up with Chosen and Select2 - but this was a few years ago 
> and I can't remember my reasons. But if it hasn't been considered, it might 
> be worth a look.
>
> Andy
>
> On 6 April 2016 at 15:20, Marc Tamlyn  
> wrote:
>
>> Agreed. I recently was trying to use a fitler horizontal widget on my 
>> phone and thought the whole thing was broken because `> multiple=mutliple>` looks so wrong. I'd love to see this experience 
>> improved, and select2 is a good reliable solution.
>>
>> On 6 April 2016 at 15:11, Aymeric Augustin > > wrote:
>>
>>> I’m OK with this. It's a reasonable solution.
>>>
>>> -- 
>>> Aymeric.
>>>
>>> On 06 Apr 2016, at 15:25, Johannes Hoppe >> > wrote:
>>>
>>> Hi,
>>>
>>> as promised I started working on an autocomplete field for 
>>> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>>>
>>> We had a longer discussion in the ticket and also at the sprints at 
>>> DjangoConEU with some of the maintainers for famous 3rd party autocomplete 
>>> integrations.
>>>
>>> We concluded that select2 is the most mature and stable solution, that 
>>> also doesn't require us to write our own JS code. (I know how much we hate 
>>> it ;)
>>>
>>> Notable:
>>> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper 
>>> around the vendored Select2 library. I think that is better than leaving 
>>> `jQuery` in the global namespace.
>>> 2. `$.select2` will only be added to `django.jQuery` and therefore not 
>>> interfere with other implementations. One should still be able to use 3rd 
>>> party libraries.
>>> 3. Select2 is unter MIT license.
>>>
>>> All in all I tried not to break anything and have this as new opt in 
>>> solution. Lets see how it plays out.
>>>
>>> All I need for you is to decided on wether or not with should vendor 
>>> Select2.
>>>
>>> PR is here: https://github.com/django/django/pull/6385
>>>
>>> Thanks in advance!
>>> Joe
>>>
>>> -- 
>>> 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-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@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/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, 

Re: Vendoring Select2

[Andrew Ingram]

In previous projects (before moving to rolling my own UI components), I
ended up favouring Selectize (http://selectize.github.io/selectize.js/)
after getting fed up with Chosen and Select2 - but this was a few years ago
and I can't remember my reasons. But if it hasn't been considered, it might
be worth a look.

Andy

On 6 April 2016 at 15:20, Marc Tamlyn  wrote:

> Agreed. I recently was trying to use a fitler horizontal widget on my
> phone and thought the whole thing was broken because ` multiple=mutliple>` looks so wrong. I'd love to see this experience
> improved, and select2 is a good reliable solution.
>
> On 6 April 2016 at 15:11, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> I’m OK with this. It's a reasonable solution.
>>
>> --
>> Aymeric.
>>
>> On 06 Apr 2016, at 15:25, Johannes Hoppe  wrote:
>>
>> Hi,
>>
>> as promised I started working on an autocomplete field for
>> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>>
>> We had a longer discussion in the ticket and also at the sprints at
>> DjangoConEU with some of the maintainers for famous 3rd party autocomplete
>> integrations.
>>
>> We concluded that select2 is the most mature and stable solution, that
>> also doesn't require us to write our own JS code. (I know how much we hate
>> it ;)
>>
>> Notable:
>> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper
>> around the vendored Select2 library. I think that is better than leaving
>> `jQuery` in the global namespace.
>> 2. `$.select2` will only be added to `django.jQuery` and therefore not
>> interfere with other implementations. One should still be able to use 3rd
>> party libraries.
>> 3. Select2 is unter MIT license.
>>
>> All in all I tried not to break anything and have this as new opt in
>> solution. Lets see how it plays out.
>>
>> All I need for you is to decided on wether or not with should vendor
>> Select2.
>>
>> PR is here: https://github.com/django/django/pull/6385
>>
>> Thanks in advance!
>> Joe
>>
>> --
>> 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%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 

Re: Vendoring Select2

[Marc Tamlyn]

Agreed. I recently was trying to use a fitler horizontal widget on my phone
and thought the whole thing was broken because ``
looks so wrong. I'd love to see this experience improved, and select2 is a
good reliable solution.

On 6 April 2016 at 15:11, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> I’m OK with this. It's a reasonable solution.
>
> --
> Aymeric.
>
> On 06 Apr 2016, at 15:25, Johannes Hoppe  wrote:
>
> Hi,
>
> as promised I started working on an autocomplete field for
> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>
> We had a longer discussion in the ticket and also at the sprints at
> DjangoConEU with some of the maintainers for famous 3rd party autocomplete
> integrations.
>
> We concluded that select2 is the most mature and stable solution, that
> also doesn't require us to write our own JS code. (I know how much we hate
> it ;)
>
> Notable:
> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper
> around the vendored Select2 library. I think that is better than leaving
> `jQuery` in the global namespace.
> 2. `$.select2` will only be added to `django.jQuery` and therefore not
> interfere with other implementations. One should still be able to use 3rd
> party libraries.
> 3. Select2 is unter MIT license.
>
> All in all I tried not to break anything and have this as new opt in
> solution. Lets see how it plays out.
>
> All I need for you is to decided on wether or not with should vendor
> Select2.
>
> PR is here: https://github.com/django/django/pull/6385
>
> Thanks in advance!
> Joe
>
> --
> 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Aymeric Augustin]

I’m OK with this. It's a reasonable solution.

-- 
Aymeric.

> On 06 Apr 2016, at 15:25, Johannes Hoppe  wrote:
> 
> Hi,
> 
> as promised I started working on an autocomplete field for 
> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
> 
> We had a longer discussion in the ticket and also at the sprints at 
> DjangoConEU with some of the maintainers for famous 3rd party autocomplete 
> integrations.
> 
> We concluded that select2 is the most mature and stable solution, that also 
> doesn't require us to write our own JS code. (I know how much we hate it ;)
> 
> Notable:
> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper around 
> the vendored Select2 library. I think that is better than leaving `jQuery` in 
> the global namespace.
> 2. `$.select2` will only be added to `django.jQuery` and therefore not 
> interfere with other implementations. One should still be able to use 3rd 
> party libraries.
> 3. Select2 is unter MIT license.
> 
> All in all I tried not to break anything and have this as new opt in 
> solution. Lets see how it plays out.
> 
> All I need for you is to decided on wether or not with should vendor Select2.
> 
> PR is here: https://github.com/django/django/pull/6385
> 
> Thanks in advance!
> Joe
> 
> -- 
> 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Collin Anderson]

Hi All,

I'm in favor of this change. This has the potential to replace the 
raw_id_fields and filter_horizontal which I think would be a huge win. 
Those widgets are out-dated not only in terms of code, but also from a UI 
point of view.

I'll try to give my answers to some questions before they come up.

- Aren't we having a discussion about adding hard-dependencies instead of 
vendoring code? Yes, and I think it's something we could consider down the 
road for this case, if our experiments with other libraries work out. This 
is little different though different because it's front-end code. For one 
thing, if we do a dependency on a 3rd party library, you'd have to add that 
library to INSTALLED_APPS for it to pick up the static files. Even then, it 
will only work if you use collectstatic (which I personally do not). Also, 
because this is front-end javascript, in theory there shouldn't be security 
holes in the code (we're not supposed to trust browser code in any case). 
Again, I think it's something we could consider down the road.

- Why select2? I haven't heard any serious proposals of a different library 
to use.

- Why not write the UI ourselves? Feel free. I spent a few hours at the 
Django Under the Hood sprints trying to write my own and it's a lot of 
work. You need to ajax-in the data, position the box in the right spot, 
handle keyboard events, etc. That's more javascript code we need to 
maintain (which, yes, we don't like doing :), and there's already a 
polished library we can use.

- Why not make it a generic form widget? I think this would be a lot more 
work. It would require adding a url endpoint and likely more configuration. 
If it's admin-only (for now), we can re-use the permission system and 
search_fields and keep it simple and seemless. I think making it generic is 
something we could consider down the road.

Thanks!
Collin

On Wednesday, April 6, 2016 at 9:25:08 AM UTC-4, Johannes Hoppe wrote:
>
> Hi,
>
> as promised I started working on an autocomplete field for 
> `django.contrib.admin` as a more convenient alternative to `row_id_fields`.
>
> We had a longer discussion in the ticket and also at the sprints at 
> DjangoConEU with some of the maintainers for famous 3rd party autocomplete 
> integrations.
>
> We concluded that select2 is the most mature and stable solution, that 
> also doesn't require us to write our own JS code. (I know how much we hate 
> it ;)
>
> Notable:
> 1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper 
> around the vendored Select2 library. I think that is better than leaving 
> `jQuery` in the global namespace.
> 2. `$.select2` will only be added to `django.jQuery` and therefore not 
> interfere with other implementations. One should still be able to use 3rd 
> party libraries.
> 3. Select2 is unter MIT license.
>
> All in all I tried not to break anything and have this as new opt in 
> solution. Lets see how it plays out.
>
> All I need for you is to decided on wether or not with should vendor 
> Select2.
>
> PR is here: https://github.com/django/django/pull/6385
>
> Thanks in advance!
> Joe
>

-- 
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/c2c6fd19-da23-4f11-9465-6816681d3aa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Vendoring Select2

[Johannes Hoppe]

Hi,

as promised I started working on an autocomplete field for 
`django.contrib.admin` as a more convenient alternative to `row_id_fields`.

We had a longer discussion in the ticket and also at the sprints at 
DjangoConEU with some of the maintainers for famous 3rd party autocomplete 
integrations.

We concluded that select2 is the most mature and stable solution, that also 
doesn't require us to write our own JS code. (I know how much we hate it ;)

Notable:
1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper around 
the vendored Select2 library. I think that is better than leaving `jQuery` 
in the global namespace.
2. `$.select2` will only be added to `django.jQuery` and therefore not 
interfere with other implementations. One should still be able to use 3rd 
party libraries.
3. Select2 is unter MIT license.

All in all I tried not to break anything and have this as new opt in 
solution. Lets see how it plays out.

All I need for you is to decided on wether or not with should vendor 
Select2.

PR is here: https://github.com/django/django/pull/6385

Thanks in advance!
Joe

-- 
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/21cbed67-1ecb-4e04-a8d6-746cb363beab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[Marc Tamlyn]

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.

Re: New `pre_handler()` method on Class-Based Views

[Diederik van der Boor]

Too bad the issue was already closed.

I’ve added my 2 cents: 
https://github.com/django/django/pull/6416#issuecomment-206301186
I’d expect having a View.setup() method would simplify things for both simple 
use case and complex projects.

Best,
Diederik

> Op 5 apr. 2016, om 15:20 heeft Tim Graham  het volgende 
> geschreven:
> 
> See the discussion on the pull request: 
> https://github.com/django/django/pull/6416 
> 
> 
> Aymeric says, "The GCBV API is already widely criticized for being too 
> complicated. I think that adding one method to save one line of code is a bad 
> trade-off. I'm -1."
> 
> On Sunday, April 3, 2016 at 3:35:26 PM UTC-4, Ryan Hiebert wrote:
> I have taken to using a prepare method called from dispatch which takes the 
> request  args, and I use it primarily to resolve ids in the url to db 
> objects. This sounds like it fills a similar purpose.
> 
> Sent from my iPhone
> 
> On Apr 3, 2016, at 14:07, Pablo Recio  
> wrote:
> 
>> Hey there,
>> 
>> Wanted to share an idea I had during some discussions in DjangoCon EU. When 
>> using CBV, sometimes we have to replicate behaviour between different 
>> handlers. For instance setting up certain objects, extra user checks... 
>> Normally the way to achieve this is to override the `dispatch()`, but it's a 
>> bit error-prone and doesn't feel too clean sometimes.
>> 
>> So I wrote a little piece of code that adds a `pre_handler()` method that 
>> gets called before the handler method, whatever that is. Here is the code: 
>> https://github.com/pablorecio/django/tree/pre-handler-view-method 
>> , if it's 
>> something that would get merged I'll happily submit a PR.
>> 
>> Thanks!
>> Pablo Recio
>> 
>> 
>> 
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/df0c7703-b496-4bfa-ad31-68b35be482fa%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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/087bc5f9-6aed-4614-ba66-b40815405d2d%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/22D78BAF-81A1-45C8-A6FB-C2A8FC786491%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

django-firebird for django 1.8.x alpha

[mariuz]

The current master branch is being developed under django 1.8.x

This is still in alpha status but I think the base code works pretty well.

Any feedback wiil be appreciated.


https://github.com/maxirobaina/django-firebird/commits/master

-- 
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/dcfb44eb-8dd0-49b0-817e-4576097e5d32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add documentation to address OWASP Top 10?

[Erik Cederstrand]

> Den 6. apr. 2016 kl. 07.29 skrev Anssi Kääriäinen :
> 
> It is notable that if the number of items is a secret (say, you don't
> want to reveal how many sales items you have), just having information
> about sequential numbers is bad. In that case you should use UUID,
> which the documentation could point out.

If anything about your data is sensitive, then there are a pile of side 
channels that putting your data online could expose. URLs are just one. For an 
entertaining read, google "German tank problem".

Giving specific security advice in the documentation that doesn't strictly 
refer to Django features could IMO lead to the false expectation that you're 
magically secure if you follow the advice. I would prefer that the 
documentation simply pointed to further reading, e.g. OWASP.

Erik

-- 
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/D9FBFA53-1053-4389-A192-3FA44606C82D%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Add documentation to address OWASP Top 10?

[Curtis Maloney]

On 06/04/16 11:35, Josh Smeaton wrote:

I like the idea of addressing the OWASP top 10. Further, I think the
advice of obscuring keys is wrong. The problem is actually addressed in
the OWASP Top 10[0]

*4 Insecure Direct Object References:*
A direct object reference occurs when a developer exposes a reference to
an internal implementation object, such as a file, directory, */or
database key/*. Without an access control check or other protection,
attackers can manipulate these references to access unauthorized data.

The proper solution is *Access Controls* like the Permissions system
provides.


Exactly... or just filtering the queryset according to the logged in 
User, and returning a 404 otherwise -- get_object_or_404 can make this 
trivial...


(yes 404, as 403 potentially admits the existence of the record in 
question -- see GitHub's behavior)


--
Curtis

--
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/5704BE62.1040706%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Add documentation to address OWASP Top 10?

[Aymeric Augustin]

That was my thinking as well.

This is a basic topic when it comes to web security. We can point to the OWASP 
10 but I don’t think it’s reasonable cram a complete course about web security 
into Django’s documentation, let alone maintain it. Django’s docs will never 
contain everything one may need to know to write any project that may take 
advantage of Django.

-- 
Aymeric.

> On 06 Apr 2016, at 03:35, Josh Smeaton  wrote:
> 
> I like the idea of addressing the OWASP top 10. Further, I think the advice 
> of obscuring keys is wrong. The problem is actually addressed in the OWASP 
> Top 10[0]
> 
> 4 Insecure Direct Object References:
> A direct object reference occurs when a developer exposes a reference to an 
> internal implementation object, such as a file, directory, or database key. 
> Without an access control check or other protection, attackers can manipulate 
> these references to access unauthorized data.
> 
> The proper solution is *Access Controls* like the Permissions system 
> provides. If you're going to rely on obscurity (one time file downloads for 
> example), then you want to do so with a UUID or some kind of cryptohash (I 
> haven't verified the particulars, don't take my this comment as security 
> advice). That's not appropriate for something like a comments system.
> 
> [0] https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013
> 
> -- 
> 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/0ca48548-6c6f-4d80-b166-ff49487ff3cb%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/83D4152D-7356-4DC1-A9B3-00BFA2C96F53%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.