Re: Responsive admin

[elky]

Bump!

Sorry for so long silence. Seems it's done - I added some more tweaks to 
the app.

Regarding third-party apps, I think the most less-painful ways to disable 
responsive css are:
- override responsive.css or make it empty;
- override admin base.html to remove  tag which 
enables responsive stuff for devices (it won't help for desktop browsers).


I prepared demo site for quick testing, it contains few models with some 
non-trivial admin features. Feel free to test it on your device!   

http://demo.elky.me/
login: demo
password: demo

Any CSS problems? Please report here 
.
If you think to add more admin features to test (I missed something or you 
have complex example) please create an issue or submit pull request here 
.

Thanks

-- 
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/15f742c3-5088-4259-8ba5-29720c3fc72a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django directory design philosophy question

[Adam Johnson]

1. I don't see why not. Even DRF apps need urls.py files right?
2. I think this is a minor issue and not worth worrying about, newbies
should be able to move files and folders around appropriately on the
filesystem. It's cleaner to put things in a subdirectory as it lowers the
risk of overwriting existing files in the current directory.

On 27 May 2017 at 02:51, 左小龙  wrote:

> 1. Why not create urls.py for every app when user run startapp command? I
> think most app need urls.py except when using other framework like
> django-rest-framework.
>
> 2. When we run `django-admin startproject mysite` will also create an
> inner directory call mysite which is very confuse to newbie.  Some people
> recommend use `django-admin startproject mysite .`(comma at the last)
> instead. Should we also recommend this in the document?
>
> --
> 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/87e879d8-3674-4b96-973d-
> f1dd0b4a1148%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

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

Re: Django directory design philosophy question

[Aymeric Augustin]

Hello,

Sorry Adam, I'm going to argue for the opposite position on both questions ;-)

I don't think it's a good idea for add urls.py to startapp for three reasons:

a. Even though Django's built-in boilerplates (startprojet and startapp) are 
fairly minimal, I've seen many projets with the dummy models, admin or tests 
module committed in a bunch of apps, creating noise. More files will make that 
problem worse. (I'll admit I'm not a huge fan of boilerplates in general.)

b. Some developers like giving each app its own URL space. Others prefer 
keeping all URLs in a central location. Small projects can stick with the 
simplest thing that works and a central URLconf does the job up to a few dozen 
routes. Large projects, by the time they become large, have had the time to 
understand the tradeoffs and figure out what structure works best for them. I 
think startapp is most useful to people with little Django experience and 
splitting urls.py is a premature optimization for them.

c. Unlike admin.py which is autodiscovered, urls.py won't do anything until 
it's referenced from the main URLconf. It would be misleading to add a module 
that doesn't work. I think the potential for confusion may outweigh the 
usefulness.

Regarding the target directory of startproject, I'm in favor of the proposal. 
Here's the background:
https://code.djangoproject.com/ticket/17503 

https://code.djangoproject.com/ticket/17042 

https://groups.google.com/forum/#!msg/django-developers/RLcKN_9zKYs/NsWYq3lVFU0J
 


The default behavior keeps biting me, even though I no longer qualify myself as 
a Django newbie, and I'm not the only one who finds it surprising. Unix 
commands operate in the current directory unless told otherwise: example: `ls` 
vs. `ls path/to/directory`.

Certainly files can be moved around after the fact — I do it every time — but 
this doesn't excuse the counter-intuitive API. I don't have the energy to argue 
for breaking backwards-compatibility here. But I'm strongly in favour of 
acknowledging this bug in the documentation (I haven't checked what it looks 
like currently).

Best regards,

-- 
Aymeric.


> On 28 May 2017, at 15:13, Adam Johnson  wrote:
> 
> 1. I don't see why not. Even DRF apps need urls.py files right?
> 2. I think this is a minor issue and not worth worrying about, newbies should 
> be able to move files and folders around appropriately on the filesystem. 
> It's cleaner to put things in a subdirectory as it lowers the risk of 
> overwriting existing files in the current directory.
> 
> On 27 May 2017 at 02:51, 左小龙  > wrote:
> 1. Why not create urls.py for every app when user run startapp command? I 
> think most app need urls.py except when using other framework like 
> django-rest-framework.
> 
> 2. When we run `django-admin startproject mysite` will also create an inner 
> directory call mysite which is very confuse to newbie.  Some people recommend 
> use `django-admin startproject mysite .`(comma at the last) instead. Should 
> we also recommend this in the document?
> 
> -- 
> 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/87e879d8-3674-4b96-973d-f1dd0b4a1148%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Adam
> 
> -- 
> 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/CAMyDDM0yrSVPaeqpP6X0h0ty%3DjvbgsBRgLr5Eg

Re: assertRaises vs. assertRaisesMessage

[Mads Jensen]

On Thursday, May 25, 2017 at 5:03:54 PM UTC+2, Shai Berger wrote:
>
> Hi, 
>
> I apologize for re-raising a thread that's mostly done and decided, but I 
> just 
> ran into [1] where it says: 
>
> """ 
> Note 
>
> Exception messages are not part of the Python API. Their contents may 
> change 
> from one version of Python to the next without warning and should not be 
> relied on by code which will run under multiple versions of the 
> interpreter. 
> """ 
>
> I don't think that's enough to overturn the decision, but I thought this 
> should be noted in this thread.
>

I asked Tim on IRC about this some weeks ago. I think it suffices to 
restrict the PR to Django's own exception messages. There are quite a lot 
of tests for IndexError, TypeError etc. which use messages from Python.

I created https://code.djangoproject.com/ticket/28224 while doing work on 
this PR.

[1] https://docs.python.org/3/reference/executionmodel.html#exceptions 
>

~ Mads 

-- 
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/3070e428-5f36-49ea-b12e-ff1fb3c79d9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django directory design philosophy question

[Adam Johnson]

On (2), cookiecutter 's behaviour
is to create a new directory and it probably gets more traffic than
startproject.

On 28 May 2017 at 15:04, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> Sorry Adam, I'm going to argue for the opposite position on both questions
> ;-)
>
> I don't think it's a good idea for add urls.py to startapp for three
> reasons:
>
> a. Even though Django's built-in boilerplates (startprojet and startapp)
> are fairly minimal, I've seen many projets with the dummy models, admin or
> tests module committed in a bunch of apps, creating noise. More files will
> make that problem worse. (I'll admit I'm not a huge fan of boilerplates in
> general.)
>
> b. Some developers like giving each app its own URL space. Others prefer
> keeping all URLs in a central location. Small projects can stick with the
> simplest thing that works and a central URLconf does the job up to a few
> dozen routes. Large projects, by the time they become large, have had the
> time to understand the tradeoffs and figure out what structure works best
> for them. I think startapp is most useful to people with little Django
> experience and splitting urls.py is a premature optimization for them.
>
> c. Unlike admin.py which is autodiscovered, urls.py won't do anything
> until it's referenced from the main URLconf. It would be misleading to add
> a module that doesn't work. I think the potential for confusion may
> outweigh the usefulness.
>
> Regarding the target directory of startproject, I'm in favor of the
> proposal. Here's the background:
> https://code.djangoproject.com/ticket/17503
> https://code.djangoproject.com/ticket/17042
> https://groups.google.com/forum/#!msg/django-developers/
> RLcKN_9zKYs/NsWYq3lVFU0J
>
> The default behavior keeps biting me, even though I no longer qualify
> myself as a Django newbie, and I'm not the only one who finds it
> surprising. Unix commands operate in the current directory unless told
> otherwise: example: `ls` vs. `ls path/to/directory`.
>
> Certainly files can be moved around after the fact — I do it every time —
> but this doesn't excuse the counter-intuitive API. I don't have the energy
> to argue for breaking backwards-compatibility here. But I'm strongly in
> favour of acknowledging this bug in the documentation (I haven't checked
> what it looks like currently).
>
> Best regards,
>
> --
> Aymeric.
>
>
> On 28 May 2017, at 15:13, Adam Johnson  wrote:
>
> 1. I don't see why not. Even DRF apps need urls.py files right?
> 2. I think this is a minor issue and not worth worrying about, newbies
> should be able to move files and folders around appropriately on the
> filesystem. It's cleaner to put things in a subdirectory as it lowers the
> risk of overwriting existing files in the current directory.
>
> On 27 May 2017 at 02:51, 左小龙  wrote:
>
>> 1. Why not create urls.py for every app when user run startapp command? I
>> think most app need urls.py except when using other framework like
>> django-rest-framework.
>>
>> 2. When we run `django-admin startproject mysite` will also create an
>> inner directory call mysite which is very confuse to newbie.  Some people
>> recommend use `django-admin startproject mysite .`(comma at the last)
>> instead. Should we also recommend this in the document?
>>
>> --
>> 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/ms
>> gid/django-developers/87e879d8-3674-4b96-973d-f1dd0b4a1148%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM0yrSVPaeqpP6X0h0ty%
> 3DjvbgsBRgLr5EgVw7wU7DgXWRg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.co

Re: Integrate dj-database-url into Django

[linus]

There's also https://github.com/doismellburning/django12factor - and it 
simplifies all the boilerplate, that is still required in django-environ, 
into:

import django12factorglobals().update(django12factor.factorise())


It would be quite nice if Django supported 12factor configuration natively, 
or at least with a single function call like this one.

Regards,
Linus

On Sunday, May 28, 2017 at 12:09:57 AM UTC+2, Tim Allen wrote:
>
> I've recently been introduced to `django-environ`, a similar library that 
> has additional features to DB connect URLs that we may want to consider: 
> https://github.com/joke2k/django-environ
>
> It has the same issue with third party DB engines; for example, I recently 
> issued a PR to include `pyodbc` as an option. It has some nice newcomer 
> friendly features, such as a cleaner way of determining BASE_URL / 
> SITE_ROOT. Have a look at the URL for a good "before" and "after" settings 
> file example.
>
> Having full support for .env files would make Django projects easier to 
> bring in line with 12-factor.
>
> Regards,
>
> Tim
>
> On Saturday, May 27, 2017 at 3:52:23 PM UTC-4, Tom Forbes wrote:
>>
>> Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any arbitrary 
>> module you give it. If we accept that then I think we are accepting the 
>> risk of imports via an attacker controlling environment variables whilst 
>> Django starts up?
>>
>> On Sat, May 27, 2017 at 8:49 PM, Tom Forbes  wrote:
>>
>>> > I'm wary of possible security ramifications: if we do this, changing a 
>>> configuration value will import an arbitrary module, which could make it 
>>> easier to run arbitrary code in some scenarios. I don't have a clear threat 
>>> model in mind here, though.
>>>
>>> Good point, it's not wise to enable this even without a clear threat 
>>> model. Django does import the settings based on an environment variable, 
>>> but it's relative and if you can use that to do anything nasty then you're 
>>> most likely already through the airtight hatch (so to speak). However 
>>> importing potentially global modules could be bad news.
>>>
>>> Ignoring it is always an option, but could we not specify that the third 
>>> party database provider has to be in the `INSTALLED_APPS`? That could 
>>> provide some form of whitelisting so not any old module is imported. Not 
>>> sure about any issues that may arise from this though.
>>>
>>> > One possibility would be to use entrypoints in setuptools, this way 
>>> 3rd party backends could specify a name which then has a fixed & verified 
>>> import path.
>>>
>>> This seems like it could get complex, and be quite unlike anything else 
>>> in Django.
>>>
>>> Perhaps just supporting this for first-party database backends is 
>>> easiest?
>>>
>>> On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin <
>>> aymeric@polytechnique.org> wrote:
>>>
 Hello,

 I'm wondering what the exact definition of the URL format is. Is it 
 specified somewhere? Or is it just:

 [engine]://[username]:[password]@[host]:[port]/[name]

 where we create arbitrary [engine] values in an ad-hoc fashion?

 On 24 May 2017, at 21:21, Tom Forbes  wrote:

 My two cents: connection strings/database URI's are a feature I've 
 sorely missed in Django.

 Built-in functionality to convert environment variables like 
 DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant 
 DATABASE setting would make some deployment situations a lot simpler. 
 Currently, unless you use dj-database-uri you have to define a bunch of 
 ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary 
 together yourself.


 Fully agreed. While relatively minor, it's an annoyance.

 How does this library complex keys like OPTIONS, TEST or DEPENDENCIES?


 I don't think it's reasonable to cram them in a URL.

 dj-database-url allows passing options as extra keyword arguments. 
 Other values should be explicitly added in the settings module, by 
 updating 
 the dict generated from the URL.

 To help support third part backends: perhaps the scheme portion of the 
 URI could be either a relative import from django.db.backends or an 
 absolute import to a third party library? It seems URI schemes can 
 have dots and underscores in them, so they can be python package paths.

 I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but 
 sqlserver_ado://xyz would resolve to the third party django-mssql engine 
 via an absolute import.


 I'm wary of possible security ramifications: if we do this, changing a 
 configuration value will import an arbitrary module, which could make it 
 easier to run arbitrary code in some scenarios. I don't have a clear 
 threat 
 model in mind here, though.

 I'd rather specify the database engine explicitly when calling 
 dj-database-u

Re: Integrate dj-database-url into Django

[Curtis Maloney]

My django-classy-settings also supports env-based settings, in a 
declarative manner with defaults.


What I've yet to crack (though the discussion is underway) is good 
formats for structured settings like caches and databases.


Generally I use dj-database-url for my own projects :)

I like the idea of having it scan INSTALLED_APPS to allow registering 
custom DB backend protocols... though I think the modern approach is 
AppConfig.ready ?


--
Curtis

On 29/05/17 08:23, li...@lew21.net wrote:

There's also https://github.com/doismellburning/django12factor - and it
simplifies all the boilerplate, that is still required in
django-environ, into:

import django12factor
globals().update(django12factor.factorise())


It would be quite nice if Django supported 12factor configuration
natively, or at least with a single function call like this one.

Regards,
Linus

On Sunday, May 28, 2017 at 12:09:57 AM UTC+2, Tim Allen wrote:

I've recently been introduced to `django-environ`, a similar library
that has additional features to DB connect URLs that we may want to
consider: https://github.com/joke2k/django-environ


It has the same issue with third party DB engines; for example, I
recently issued a PR to include `pyodbc` as an option. It has some
nice newcomer friendly features, such as a cleaner way of
determining BASE_URL / SITE_ROOT. Have a look at the URL for a good
"before" and "after" settings file example.

Having full support for .env files would make Django projects easier
to bring in line with 12-factor.

Regards,

Tim

On Saturday, May 27, 2017 at 3:52:23 PM UTC-4, Tom Forbes wrote:

Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any
arbitrary module you give it. If we accept that then I think we
are accepting the risk of imports via an attacker controlling
environment variables whilst Django starts up?

On Sat, May 27, 2017 at 8:49 PM, Tom Forbes  wrote:

> I'm wary of possible security ramifications: if we do this, 
changing a
configuration value will import an arbitrary module, which
could make it easier to run arbitrary code in some
scenarios. I don't have a clear threat model in mind here,
though.

Good point, it's not wise to enable this even without a
clear threat model. Django does import the settings based on
an environment variable, but it's relative and if you can
use that to do anything nasty then you're most likely
already through the airtight hatch (so to speak). However
importing potentially global modules could be bad news.

Ignoring it is always an option, but could we not specify
that the third party database provider has to be in the
`INSTALLED_APPS`? That could provide some form of
whitelisting so not any old module is imported. Not sure
about any issues that may arise from this though.

> One possibility would be to use entrypoints in setuptools, this
way 3rd party backends could specify a name which then has a
fixed & verified import path.

This seems like it could get complex, and be quite unlike
anything else in Django.

Perhaps just supporting this for first-party database
backends is easiest?

On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin
 wrote:

Hello,

I'm wondering what the exact definition of the URL
format is. Is it specified somewhere? Or is it just:

[engine]://[username]:[password]@[host]:[port]/[name]

where we create arbitrary [engine] values in an ad-hoc
fashion?


On 24 May 2017, at 21:21, Tom Forbes 
wrote:

My two cents: connection strings/database URI's are a
feature I've sorely missed in Django.

Built-in functionality to convert environment
variables like DJANGO_DB_DEFAULT (or more generally
DJANGO_DB_*key*) into the relevant DATABASE setting
would make some deployment situations a lot simpler.
Currently, unless you use dj-database-uri you have to
define a bunch of ad-hoc DB_USER/DB_PASSWORD etc env
variables and price the dictionary together yourself.


Fully agreed. While relatively minor, it's an annoyance.


How does this library complex keys like OPTIONS, TEST
or DEPENDENCIES?


I don't think it's reasonable to cram them in a URL.

dj-database-url allows passing options as extra keyword
arguments. Other values should be explicitly added in