Re: Making startproject's settings more 12-factor-y

[Bobby Mozumder]

I also have my own version of “startproject" that creates several additional 
files, including my web server config file (I use H20 web server, not Nginx) as 
well as a uWSGI vassals config file. I create the following preconfigured files 
and directories using a command-line Python script:

.gitignore
.env
h2o.conf
uwsgi.ini
create_db.sql
manifest.json
browserconfig.xml
robots.txt
requirements.txt
/static
/static/icons
/static/icons/*various_icons.png
/media
/venv
/log

Basically as much as I can possibly create to launch a new project and have it 
ready to deploy on my main web server.  I’m adding more items as well, 
including fonts, CSS and JS templates.

There are so many little things that are needed to deploy. I wish Django had it 
built in, but yes my configuration is pretty custom, with H20 instead of Nginx 
or Apache.

Is this something of interest for Django directly?

-bobby

> On Jun 23, 2020, at 9:08 PM, Kit La Touche  wrote:
> 
> I saw what you added; I tried to make this a minimal change, and was 
> conscious also Carl's expressed preference (which I share, tbh) in the linked 
> discussion for less-magic. I figured a function that just parsed values out 
> of the env would be the smallest possible first step, so I'm inclined to keep 
> with this, for now.
> 
> On Tue, Jun 23, 2020 at 4:15 PM Javier Buzzi  > wrote:
> I think its great, but id add a little more customizability. I've added an 
> example to your PR.
> 
> -- 
> 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/8dc94197-fa0c-442a-8f97-3d7990a3a2c2o%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/CAFcS-hD4RFMt%2BwQCCkt6TB5P3rEjarD9Bc9WcArvdaKBzxiYEw%40mail.gmail.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/3E3ED051-F766-4F0E-BD83-49503C11662A%40gmail.com.

Re: Making startproject's settings more 12-factor-y

[Kit La Touche]

I saw what you added; I tried to make this a minimal change, and was
conscious also Carl's expressed preference (which I share, tbh) in the
linked discussion for less-magic. I figured a function that just parsed
values out of the env would be the smallest possible first step, so I'm
inclined to keep with this, for now.

On Tue, Jun 23, 2020 at 4:15 PM Javier Buzzi  wrote:

> I think its great, but id add a little more customizability. I've added an
> example to your PR.
>
> --
> 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/8dc94197-fa0c-442a-8f97-3d7990a3a2c2o%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/CAFcS-hD4RFMt%2BwQCCkt6TB5P3rEjarD9Bc9WcArvdaKBzxiYEw%40mail.gmail.com.

Re: Making startproject's settings more 12-factor-y

[Javier Buzzi]

I think its great, but id add a little more customizability. I've added an 
example to your PR.

-- 
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/8dc94197-fa0c-442a-8f97-3d7990a3a2c2o%40googlegroups.com.

Re: Making startproject's settings more 12-factor-y

[Kit La Touche]

I have put in a PR (https://github.com/django/django/pull/13029) that I
think matches pretty well with the comments from Carl Meyer in the
conversation you linked. Please let me know what you think of it.

It adds a small helper function that will read an env var, optionally
coercing it to a type, optionally falling back to a default. It also makes
two of the settings in the default settings.py template (DEBUG and
SECRET_KEY) use this function, with their previous values set as defaults.

Thanks!

On Fri, Jun 5, 2020 at 4:39 PM Kit La Touche  wrote:

> I have, thank you! I tried to do my research before I wrote this email and
> this PR, but there's a ton of context to all those conversations that I'm
> sure I'd be missing, so I'm never gonna reach the point of feeling
> confident that I have a handle on what's gone before, alas.
>
> On Fri, Jun 5, 2020 at 4:03 PM Tim Graham  wrote:
>
>> Have you read past discussions on the mailing list?
>>
>> For example:
>>
>> Making Django more PaaS-friendly
>> https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion
>>
>> Searching the archives for "12-factor" yields some other results.
>>
>> That may help you to craft your proposal.
>>
>> On Friday, June 5, 2020 at 5:45:07 PM UTC-4, Kit La Touche wrote:
>>>
>>> I'm interested in reducing the distance from running `startproject` to
>>> having a deployable Django app, having recently had a number of
>>> interactions with junior devs interested in using Django but finding
>>> deployment a nightmare. Some of this is of course on the other side, on the
>>> PaaS of choice, but some of it can (and I think should) be done on the
>>> Django side.
>>>
>>> I'd like to start small. If I made a PR to replace a few key settings
>>> with "get from the env, or fall back to this default", would people be
>>> interested in approving that? I hope so!
>>>
>>> --Kit
>>>
>> --
>> 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/a45204c6-5475-4ee9-a467-78c66736cfado%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/CAFcS-hAfFWsbtjYQP%3DD92yjqNUx%2BBthffQWWkP2%2BWnGHG9__UA%40mail.gmail.com.

Re: Admin accessibility

[Thibaud Colas]

Hey Tom,

I wanted to check if there is anything we/I could do to help in the 
meantime? Whether that’s by starting to map or audit the Django admin, or 
setting up a sample CI pipeline with accessibility tests, or something else 
altogether. It’s a bit daunting to get started with this but I think I 
could realistically do one of:

1. Create a draft map of the Django admin UI for later manual auditing 
purposes.
2. Audi a specific part of Django and creating a ticket with concrete 
things to fix.
3. Set up static analysis for the CSS or HTML to look for common 
accessibility gotchas.
4. Sett up automated in-browser accessibility checks on some parts of 
Django to show what that might look like in a CI pipeline.

… and document the steps along the way, and report back here or as a ticket.

Cheers,

Thibaud

On Tuesday, May 26, 2020 at 10:22:26 AM UTC+1, Tom Carrick wrote:
>
> Some further thoughts...
>
> Mariusz, I don't think I agree that WCAG is massive. It can look a little 
> large but I think that's mostly because each guideline is split into 
> smaller pieces and it's quite wordy to avoid ambiguity. There are in 2.1 50 
> success criteria for AA, many of which can be checked automatically, and 
> many of those that can't don't apply to us as we don't use audio / video. 
> There's also a nice quick reference 
>  that can be filtered to remove 
> AAA and anything else unwanted. Once you drill down it can again get quite 
> wordy, but it covers a lot. I think it's worth remembering here is that the 
> point is not to strictly adhere to a standard for the sake of it, just to 
> improve the overall accessibility, and WCAG is a useful and measurable tool 
> to get us some of the way there.
>
> Thibaud, I more or less agree with everything there. I'm not sure 
> developers should have to do full accessibility checks for their changes in 
> the admin. Using a screen reader for example can be very frustrating and 
> confusing if you're not used to it, and it can take an inordinate amount of 
> time, and I don't really wish that burden on (for example) first time 
> committers who already have a lot of stuff to do, I think this will only 
> discourage contributions. I think it should be the responsibility of the 
> accessibility team to provide feedback, suggestions, etc. on relevant PRs 
> or fix things when they're noticed after manual audits.
>
> ATAG looks handy, but at first glance we couldn't even get to A, it 
> requires auto-saving. It also generally seems like something that would 
> cover a rich text editor plugged into the admin more than the admin itself, 
> though I think it's laudable as a future target.
>
> The more I think about it, I think the DEP should be a process DEP rather 
> than a feature DEP. As others have mentioned, we don't need a DEP to fix 
> accessibility issues - just fix them. But forming a team seems useful, and 
> I think a DEP is required for that. I think the DEP should be limited to:
>
> 1. The accessibility team, how membership is decided, who it's accountable 
> to, it's role/responsibilities, etc.
> 2. Perhaps the initial standard(s) to target, although this could also be 
> decided by the a11y team post-assembly and agreed with the technical board 
> and/or core devs.
>
> As I said, I'm happy to write up the DEP, but since it'll be a process 
> DEP, I think I'd need the support of a core dev, someone on the technical 
> board, or just someone who has more knowledge of Django's "bureaucracy", 
> for lack of a better word.
>
> Tom
>
> On Tue, 26 May 2020 at 01:20, Thibaud Colas  > wrote:
>
>> Hi Tom,
>>
>> It’s exciting to see this getting started! To me a DEP would be highly 
>> beneficial, because there is a lot to this that goes beyond finding and 
>> fixing individual issues – it’s more about detailing the a process for 
>> parts of Django to stay accessible over time. Here are things I’d suggest 
>> to cover, in addition to your list:
>>
>> - Going further than the targeted standard and tests in CI –  outline 
>> clear steps developers should take when testing their work: using developer 
>> tools, screen readers, etc. It’s not practical to just state the standard 
>> as WCAG is quite big, and open to interpretation. And CI testing will never 
>> be enough to reach any degree of compliance.
>>   - I’m not familiar with Django’s development process but generally I 
>> would recommend to use a combination of linting, browser extensions, manual 
>> testing instructions – and CI tests.
>> - If the accessibility team was to cover more than the Django admin, I 
>> think it would be worthwhile to also include accessibility of sites built 
>> with Django. Django is largely unopinionated about markup, but I remember 
>> its forms markup not being particularly good for screen readers, and the 
>> HTML code snippets in the docs would also be worth reviewing.
>> - Same goes for admin docs – not too familiar with them myself so I’m not 

Fellow Reports -- June 2020

[Carlton Gibson]

Hi all. 


Calendar Week 23 -- ending 07 June.


Released Django 3.0.7 and 2.2.13. 


Triaged:

https://code.djangoproject.com/ticket/31638 -- On Mysql/Sqlite, 
db.models.functions.Now uses wrong timezone (needsinfo)
https://code.djangoproject.com/ticket/31656 -- Help Texts in 
UserCreationForm cannot be overridden (Invalid)
https://code.djangoproject.com/ticket/31626 -- Add ASGI support to 
runserver (Accepted)
https://code.djangoproject.com/ticket/17613 -- Add validation method for 
cache keys. (Fixed by 2c82414.)



Reviewed:

https://code.djangoproject.com/ticket/31654 -- Memcached key validation 
raises InvalidCacheKey with clunky message.
https://github.com/django/django/pull/11991 -- Fixed #30913 -- Added 
support for covering indexes on PostgreSQL 11+.
https://github.com/django/django/pull/12915 -- Fixed #31594 -- Added 
ASGIStaticFilesHandler.get_response_async().
https://github.com/django/django/pull/12957 -- Fixed #30134 -- Ensured 
unlocalized numbers are string representation in templates.
https://github.com/django/django/pull/12976 -- Preferred usage of 
among/while to amongst/whilst.
https://github.com/django/django/pull/12997 -- Removed reference to 
unsupported versions of Django and Python.
https://github.com/django/django/pull/12970 -- Updated how to install 
Django on windows docs.
https://github.com/django/django/pull/12267 -- Refs #30190 -- JSONL support 
addded
https://github.com/django/django/pull/12999 -- Refs #30997 -- Improved 
HttpRequest.is_ajax() warning message with stacklevel=2.
https://github.com/django/django/pull/13004 -- Updated link to Celery.
https://github.com/django/django/pull/12996 -- Fixed #31643 -- Changed 
virtualenv doc references to Python 3 venv.
https://github.com/django/django/pull/13005 -- Make the URL shade-throwing 
a bit less pointed in the tutorial
https://github.com/django/django/pull/13001 -- Normalized spelling of 
system-wide in docs.



Authored:

https://github.com/django/django/pull/13008 -- [3.0.x] Refs #31485 -- 
Backported jQuery upgrade to 3.5.1.
https://github.com/django/django/pull/13007 -- [2.2.x] Refs #31485 -- 
Backported jQuery upgrade to 3.5.1.
https://github.com/django/django/pull/13006 -- Refs #31485 -- Added release 
notes for backport of jQuery upgrade to 3.5.1.
https://github.com/django/djangoproject.com/pull/1001 -- Added 
#BlackLivesMatter banner



Calendar Week 24 -- ending 14 June.


"Vacation" (2020-style: at home. But much needed and refreshing 
nonetheless. )



Calendar Week 25 -- ending 21 June.


Triaged:

https://code.djangoproject.com/ticket/31716 -- django-admin runserver 
mostly does not work on Windows (Accepted)
https://code.djangoproject.com/ticket/31715 -- Documentation : Customize 
the admin look and feel (invalid)
https://code.djangoproject.com/ticket/31520 -- ManifestStaticFilesStorage 
should not raise ValueError on missing file when manifest_strict=False 
(wontfix)
https://code.djangoproject.com/ticket/31705 -- Bad way to select default 
filter parameter from n total link (invalid)
https://code.djangoproject.com/ticket/31700 -- Highlight destructive 
operations in makemigrations output (needsinfo)



Reviewed:

https://github.com/django/django/pull/12979 -- Fixed #6933 -- Added support 
for searching against quoted phrases in ModelAdmin.search_fields.
https://github.com/django/django/pull/12646 -- Fixed #31169 -- Adapted the 
parallel test runner to use spawn. [GSoC]
https://github.com/django/django/pull/13077 -- Fixed #31716 -- Fixed 
detection of console scripts in autoreloader on Windows.
https://github.com/django/django/pull/13079 -- Refs #31670 -- Renamed 
whitelist argument and attribute of EmailValidator.
https://github.com/django/django/pull/13071 -- Refs #28077 -- Added 
opclasses to Index.__repr__().
https://github.com/django/django/pull/13075 -- Reverted Pinned 
asgiref == 3.2.7 in test requirements.
https://github.com/django/django/pull/13076 -- Refs #30190 -- Minor edits 
to JSONL serializer.
https://github.com/django/django/pull/12267 -- Fixed #30190 -- Added JSONL 
serializer.
https://github.com/django/django/pull/12817 -- Fixed #31520 -- Corrected 
ManifestStaticFilesStorage handling of missing files.
https://github.com/django/django/pull/13045 -- Fixes #30933 -- Updated 
installation instructions for GeoDjango depencies on Windows.
https://github.com/django/django/pull/13069 -- Pinned asgiref == 3.2.7 in 
test requirements.



Authored:

https://github.com/django/django/pull/13072 -- Removed unsupported 
third-party backends from docs.



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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7b64998c-44b0-4cdf-89de-413c3c7c5bcao%40googlegroups.com.

Re: The blacklist / master issue

[Mark Bailey]

+1 on a good decision to make this change.

-- 
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/1e3d742a-7f38-4258-a5a3-bfb01a333020o%40googlegroups.com.