date:20200514

Re: Django Version 3.2 Roadmap

2020-05-14 Thread charettes

Proposal looks good to me.

+1 to moving to the 6th of April, I remember it caused a bit of confusion 
in the past and we should avoid that particularly for a LTS release.

Thanks Carlton.

Le mercredi 13 mai 2020 11:08:18 UTC-4, Markus Holtermann a écrit :
>
> Hi Carlton, 
>
> thank you. The proposal looks good to me. +1 
>
> Cheers, 
>
> Markus 
>
> On Wed, May 13, 2020, at 2:51 PM, Carlton Gibson wrote: 
> > Hi all. 
> > 
> > I've prepared a draft of the Roadmap for Django 3.2 here: 
> > 
> > https://code.djangoproject.com/wiki/Version3.2Roadmap 
> > 
> > Following the established release cadence, Django 3.2 will be due in 
> > April 2021. 
> > 
> > The key dates are these. 
> > 
> > ` 
> > = == 
> > January 14, 2021 Django 3.2 alpha; feature freeze. 
> > 
> > February 18 Django 3.2 beta; non-release blocking bug fix freeze. 
> > 
> > March 18 Django 3.2 RC 1; translation string freeze. 
> > 
> > April 1 Django 3.2 final 
> > = == 
> > ` 
> > 
> > In accordance with DEP 10, I'd like to ask the Technical Board to 
> > review this when able, and approve it or suggest adjustments if needed. 
> > 
> > Thanks. 
> > 
> > Kind Regards, 
> > 
> > Carlton 
> > 
> > 
> > 
> > 
> >  -- 
> >  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-d...@googlegroups.com . 
> >  To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/d19d3303-34aa-4e87-b867-04e7b48f81a5%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/d19d3303-34aa-4e87-b867-04e7b48f81a5%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
>

-- 
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/466fe5e6-55d5-4619-92a5-bf18064f844d%40googlegroups.com.

Re: Proposal: django project name

2020-05-14 Thread Dan Davis

>
> Wherever you place the template, users can already override it by creating
> one in their project with the same name, in an app that appears first in
> INSTALLED_APPS. There's a documentation page on this topic:
> https://docs.djangoproject.com/en/3.0/howto/overriding-templates/
> Alternatively, you can tell users to install their own URL mapped to their
> own override template. It would only be one line of configuration, the same
> as using include() to include your URLconf. And it would allow users to
> serve your app at multiple URL's or with more complicated patterns.


Yes! And in apps designed to be re-used, this can be made really good with
clever template design. I generally have *all* my templates extend a base
template, so that my users can override one simple template, and reskin my
pages simply -- assuming they use Bootstrap 3 4. So, mileage may vary.

I have also used drf-yasg, and other third party packages that provide
reusable apps. It truly is not hard to override their templates, but as
Adam is saying, you want to guide your users as to how to extend/embed and
accommodate that.  What I describe above is only one such method.

On Thu, May 14, 2020 at 4:47 PM Adam Johnson  wrote:

> Hi Christian
>
>
>> TL;DR: Django has no (builtin/explicit) settings variable like
>> PROJECT_NAME. Should have.
>>
>
> I can see how it would be useful in several situations. But in most
> long-lived projects I've come across, the "project name" is different to
> the website name (or names, plural, if it has evolved into multiple
> brands). Additionally, there's already the ability for a "Site name"
> through the contrib.sites framework, and translations complicate the idea
> of a single name. I'm not sure *another* axis of naming would make things
> easier. Sticking to Python imports and file paths to glue together things
> in code seems favourable.
>
>> When it comes to frontends, it's worse. In my case, my GDAPS module
>> enables a Vue.js frontend, which needs a index.html which loads Vue. This
>> file is (in SPA apps) the only file which is rendered using Django
>> templates. No problem, put in gdaps' templates directory and go. Works
>> fine, as long as the user of GDAPS is fine with my shipped index.html and
>> the corresponding pre-defined url path that renders that index file using
>> TemplateView.
>>
>> If he wants to override that file using his own template (with maybe
>> another font loaded etc.) I first thought I just change GDAPS to
>> dynamically load the template in GDAPS' urls.py - but therefore it should
>> know the name of the project it is a part of.
>>
> Wherever you place the template, users can already override it by creating
> one in their project with the same name, in an app that appears first in
> INSTALLED_APPS. There's a documentation page on this topic:
> https://docs.djangoproject.com/en/3.0/howto/overriding-templates/
>
> Alternatively, you can tell users to install their own URL mapped to their
> own override template. It would only be one line of configuration, the same
> as using include() to include your URLconf. And it would allow users to
> serve your app at multiple URL's or with more complicated patterns.
>
> Thanks,
>
> Adam
>
> On Wed, 13 May 2020 at 21:13, Christian González <
> christian.gonza...@nerdocs.at> wrote:
>
>> Hi all,
>>
>> I didn't find anything about that in the archive here, so I'd like to
>> come to you with an idea which is either very dumb (please tell me) or I
>> don't know why anyone hasn't thought about it...
>>
>> I'm starting a bigger project with a self-created plugin system (GDAPS,
>> alrady mentioned). Working nicely, but I came across a few Django
>> shortcomings which are sometimes easy to workaround, but could be done
>> better: the django project name.
>>
>> TL;DR: Django has no (builtin/explicit) settings variable like
>> PROJECT_NAME. Should have.
>>
>> Long version:
>>
>> If you have (like in my case) an application which is more than a single
>> django app, and could have various 3rd party additions/plugins, there is no
>> common sense of retrieving the overall "name" of the application. If you
>> create a project using django-admin startproject myproject - the name
>> says it, you name the project. It is written into various places, mostly
>> comments etc.:
>>
>> foo/asgi.py:ASGI config for foo project.
>> foo/asgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE',
>> 'foo.settings')
>> foo/settings.py:Django settings for foo project.
>> foo/settings.py:ROOT_URLCONF = 'foo.urls'
>> foo/settings.py:WSGI_APPLICATION = 'foo.wsgi.application'
>> foo/urls.py:"""foo URL Configuration
>> foo/wsgi.py:WSGI config for foo project.
>> foo/wsgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE',
>> 'foo.settings')
>> manage.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE',
>> 'foo.settings')
>>
>> But foo is no variable. Needers of this inofficial project name use
>> workarounds like settings.ROOT_URLCONF[0] to get that name. But that's
>>

Re: Proposal: django project name

2020-05-14 Thread Adam Johnson

Hi Christian


> TL;DR: Django has no (builtin/explicit) settings variable like
> PROJECT_NAME. Should have.
>

I can see how it would be useful in several situations. But in most
long-lived projects I've come across, the "project name" is different to
the website name (or names, plural, if it has evolved into multiple
brands). Additionally, there's already the ability for a "Site name"
through the contrib.sites framework, and translations complicate the idea
of a single name. I'm not sure *another* axis of naming would make things
easier. Sticking to Python imports and file paths to glue together things
in code seems favourable.

> When it comes to frontends, it's worse. In my case, my GDAPS module
> enables a Vue.js frontend, which needs a index.html which loads Vue. This
> file is (in SPA apps) the only file which is rendered using Django
> templates. No problem, put in gdaps' templates directory and go. Works
> fine, as long as the user of GDAPS is fine with my shipped index.html and
> the corresponding pre-defined url path that renders that index file using
> TemplateView.
>
> If he wants to override that file using his own template (with maybe
> another font loaded etc.) I first thought I just change GDAPS to
> dynamically load the template in GDAPS' urls.py - but therefore it should
> know the name of the project it is a part of.
>
Wherever you place the template, users can already override it by creating
one in their project with the same name, in an app that appears first in
INSTALLED_APPS. There's a documentation page on this topic:
https://docs.djangoproject.com/en/3.0/howto/overriding-templates/

Alternatively, you can tell users to install their own URL mapped to their
own override template. It would only be one line of configuration, the same
as using include() to include your URLconf. And it would allow users to
serve your app at multiple URL's or with more complicated patterns.

Thanks,

Adam

On Wed, 13 May 2020 at 21:13, Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi all,
>
> I didn't find anything about that in the archive here, so I'd like to come
> to you with an idea which is either very dumb (please tell me) or I don't
> know why anyone hasn't thought about it...
>
> I'm starting a bigger project with a self-created plugin system (GDAPS,
> alrady mentioned). Working nicely, but I came across a few Django
> shortcomings which are sometimes easy to workaround, but could be done
> better: the django project name.
>
> TL;DR: Django has no (builtin/explicit) settings variable like
> PROJECT_NAME. Should have.
>
> Long version:
>
> If you have (like in my case) an application which is more than a single
> django app, and could have various 3rd party additions/plugins, there is no
> common sense of retrieving the overall "name" of the application. If you
> create a project using django-admin startproject myproject - the name
> says it, you name the project. It is written into various places, mostly
> comments etc.:
>
> foo/asgi.py:ASGI config for foo project.
> foo/asgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')
> foo/settings.py:Django settings for foo project.
> foo/settings.py:ROOT_URLCONF = 'foo.urls'
> foo/settings.py:WSGI_APPLICATION = 'foo.wsgi.application'
> foo/urls.py:"""foo URL Configuration
> foo/wsgi.py:WSGI config for foo project.
> foo/wsgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')
> manage.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE',
> 'foo.settings')
>
> But foo is no variable. Needers of this inofficial project name use
> workarounds like settings.ROOT_URLCONF[0] to get that name. But that's
> always a bit of a whacky feeling when I do it - doesn't seem like - "I'm
> sure this will be supported for the next 20 years".
>
> When it comes to frontends, it's worse. In my case, my GDAPS module
> enables a Vue.js frontend, which needs a index.html which loads Vue. This
> file is (in SPA apps) the only file which is rendered using Django
> templates. No problem, put in gdaps' templates directory and go. Works
> fine, as long as the user of GDAPS is fine with my shipped index.html and
> the corresponding pre-defined url path that renders that index file using
> TemplateView.
>
> If he wants to override that file using his own template (with maybe
> another font loaded etc.) I first thought I just change GDAPS to
> dynamically load the template in GDAPS' urls.py - but therefore it should
> know the name of the project it is a part of.
>
> I can do that using a setting named PROJECT_NAME and place a url
> definition like
>
> path("", 
> TemplateView.as_view(template_name=os.path.join(settings.ROOT_URLCONF[0],"index.html")),
>  name="app")
>
> into urls.py. So the user can place an index.html into foo/templates/foo/ and 
> it should work.
>
> But as said, this seems to me as - hey, ROOT_URLCONF[0] - really, this is the 
> project name?
> path("", 
> TemplateView.as_view(template_name=os.path.join(settings.PR

Django 3.1 alpha 1 released

2020-05-14 Thread Mariusz Felisiak


Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2020/may/14/django-31-alpha-1-released/

--
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/3c9e3956-91e6-3549-f500-f0ff5f3b73b9%40gmail.com.

Re: Django Version 3.2 Roadmap

2020-05-14 Thread Adam Johnson

>
> did we actually do that several times before?


>From https://pypi.org/project/Django/#history , the following feature
versions were released on April 1:

   - 2.2
   - 1.8

And these minor versions:

   - 3.0.5
   - 2.2.12
   - 2.1.8
   - 1.9.5
   - 1.8.12

I’d probably just push it for the 6th in this case, after the weekend.
>

+1 for that.

Florian's right, it can be a high tension day, and we don't want to get
lost in the noise.

On Thu, 14 May 2020 at 06:22, Carlton Gibson 
wrote:

> I’d probably just push it for the 6th in this case, after the weekend.
>
> (I obviously live a sheltered life: April fools never occurred to me... 😳)
>
> On Thu, 14 May 2020 at 00:02, Florian Apolloner 
> wrote:
>
>> On Wednesday, May 13, 2020 at 4:40:55 PM UTC+2, Adam Johnson wrote:
>>>
>>> This looks good to me, it fits the preset release cadence. Although the
>>> final release will be on "April fools day," it's something we've done
>>> several times before.
>>>
>>
>> While we might have done it (did we actually do that several times
>> before?), I'd like to suggest moving it  to April 10th. (or whatever suits
>> us). Every year the first of April seems to be a high tension day, if there
>> is no necessity to release on such a day I'd strongly recommend against it.
>> It is just easier on the brain if you read a news article and you don't
>> have to decide if it is a possible prank simply because it is fools day. I
>> realize that you cannot trust news any other day either, by why pile onto
>> that if you don't have a reason…
>>
>> --
>> 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/f9e3c147-06d8-4b3d-a250-cd3a8d00af90%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAJwKpyTNoLFojY%2BGyaTta6FqPkAA40nK48BFJW--SwCoiyX19A%40mail.gmail.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1g%3DFGyNOJK8yy4P_3afGyhZrcZ8RJz7ydkg7KMXmO%2BmQ%40mail.gmail.com.

Re: Django Version 3.2 Roadmap

Re: Proposal: django project name

Re: Proposal: django project name

Django 3.1 alpha 1 released

Re: Django Version 3.2 Roadmap

5 matches

Site Navigation

Mail list logo

Footer information