Re: Improvements to the startproject template

2022-07-28 Thread Michael
Problem with adam's solutions is then where do you place the 
project's urls.py, asgi.py and wsgi.py? Normally they are in the project 
dir next to settings.py.
With regards to two dirs with same name, I call the outer dir 'src', which 
usually has related files/dirs for the project next to it, but are not part 
of the python source, e.g. requirements.txt

On Friday, 22 April 2022 at 19:31:03 UTC+2 fli...@peregrinesalon.com wrote:

> Thanks for the excellent feedback, folks. It does sound like we've built a 
> consensus for merging this PR, with other iterative improvements possible 
> later. I like the template idea, but also know that the vast majority of 
> newcomers are going to go with the default.
>
> Once I get the go-ahead from someone with Merger permissions, I'll go 
> ahead and make the changes necessary to the documentation (such as the 
> Tutorial) so we can complete this.
>
> On Thursday, April 21, 2022 at 6:01:17 PM UTC-4 pyt...@ian.feete.org 
> wrote:
>
>> I want to add that I think either proposed change here would be an 
>> improvement and that I'd prefer not to see this idea die because of 
>> bikeshedding over the best option.
>>
>> Regards,
>> Ian
>>
>> On Thu, 21 Apr 2022 at 19:21, ome chukwuemeka  
>> wrote:
>>
>>> I think this is a good suggestion!
>>>
>>> On Thu, Apr 21, 2022, 7:08 PM Albert  wrote:
>>>
 It is possible to do in current version of Django with two lines of 
 code:

 mkdir my_project

 django-admin startproject config my_project

 I have been working for many companies that use Django and I have seen 
 that each ot them has their own structure of project. 

 And usually project is created once per couple of months, so I don't 
 see advantages of changing project structure.

 Regards,

 Albert

 Temat: Re: Improvements to the startproject template 

 As there are different preferences and some see the change as worse 
 than the default and there is already a way to change the template for 
 startproject, wouldn't it be easier to provide different templates and 
 list 
 them in the documentation, so that they can be used with the --template 
 argument? With a short section about each template and the pros and the 
 cons, and for what kind of project one is better suited.

 Maybe the three top templates could be shipped directly with django, so 
 that users could choose one with --template=simple, --template=nested or 
 --template=config or something in that direction.
 On Thursday, April 21, 2022 at 11:16:23 AM UTC+2 ator...@redhat.com 
 wrote:

> I personally dislike Adam's suggestion and feel like it makes it worse 
> than the current default, but to each their own.
>
> I do prefer the proposed solution of the config directory, I am 
> working on two django projects in parallel and one follows the proposed 
> config scheme and the other doesn't (uses the default) and I find the 
> proposed config scheme more natural to use and navigate, so that's a +1 
> from me too
>
> On Thursday, April 21, 2022 at 5:10:06 AM UTC+2 pem...@gmail.com 
> wrote:
>
>> For what it's worth, this is the (general) layout I've used for the 
>> past 8+ years of my professional Django development.
>>
>> Arthur
>>
>> On Wed, 20 Apr 2022 at 15:22, Olivier Dalang  
>> wrote:
>>
>>> +1 for Adam's suggestion, I use it as well and like it very much.
>>>
>>> > root folder
>>> - manage.py
>>> - ...
>>> > myproject
>>> - __init__.py
>>> - settings.py
>>> - urls.py
>>> - ...
>>> > myapp
>>> - __init__.py
>>> - models.py
>>> - ...
>>>
>>> Pros:
>>> - everything is well namespaced under myproject 
>>> (`myproject.settings`, quite straightforward)
>>> - makes it clear that `settings.py`, `urls.py`, etc. concern the 
>>> project as a whole, and not just an app.
>>> - also nice in settings.INSTALLED_APPS (`myproject.myapp` makes it 
>>> clear that myapp is part of this project)
>>> - it leaves the root level for stuff like .gitignore, db.sqlite, 
>>> etc, so the actual source stays clean from such files.
>>> - having a parent package allows (does not require) relative imports 
>>> across modules of the same project, which more clearly conveys that 
>>> such 
>>> apps are tightly coupled
>>> - with manage.py still in the root folder, you don't need to cd into 
>>> any folder to start working
>>>
>>> I use it all the time.
>>>
>>> Cheers,
>>>
>>> Olivier
>>>
>>>
>>>
>>>
>>> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a 
>>> écrit :
>>>
 I prefer Adam's suggestion in the forum post as it lets you 
 namespace everything under your 

Settings namespaced by app_label

2022-07-28 Thread Michael
Models and URLSs (kind of) are namespaced by the *app_label*.
I am making a Django CSS app to open source, and it requires settings. For 
now I am just going to copy DRF and use a dict to avoid collisions.

What if in *settings.py* we could do something like this (where one has an 
app with an app_label of 'foo'):
FOO_SETTINGS = {
   'POGO_STICKS': 5,
   'MORE_SETTINGS': [1,2,3],
}

or (what I think is better) use class based approach:
# Here DjangoAppSettings is just a subclass of maybe a dataclass, to use in 
isintance tests to find the settings (like how TestCase's are found).
FooSettings(DjangoAppSettings):
   POGO_STICKS = 5
   MORE_SETTINGS = [1,2,3]

Then in the app that consumes the settings, maybe do something like this 
(or something different):
from django.conf import settings
apps.get_app_config('foo').settings

And it would return *FooSettings*
I have not given it much thought, but its just concept I am proposing, not 
the exact implementation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d4746049-eac2-4ad6-80b5-2b1886bc4498n%40googlegroups.com.


Re: Deprecate CICharField, CIEmailField, CITextField

2022-07-28 Thread Mariusz Felisiak
https://code.djangoproject.com/ticket/33872

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d1b3219e-7152-46b8-8e41-a315181f1203n%40googlegroups.com.


Re: Deprecate CICharField, CIEmailField, CITextField

2022-07-28 Thread Mariusz Felisiak
> Support for PostgreSQL 10 was dropped in Django 4.1, and support for 
PostgreSQL 11 was dropped in Django 4.2.

When CICharField, CIEmailField, CITextField deprecation starts in Django 
4.2 they will be removed in Django 5.1.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8133c26-b409-42f9-b0f2-bda699e467ban%40googlegroups.com.