Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.d95ef6261eb38525beaefd672056cfad%40djangoproject.com.

Re: [Django] #32272: gettext_lazy inconsistent error when nested

[Django]

#32272: gettext_lazy inconsistent error when nested
--+
 Reporter:  John Bazik|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * component:  Utilities => Internationalization
 * stage:  Unreviewed => Accepted


Comment:

 I'll accept this, since there is a difference in behaviour.

 Given the code in `trans_null.py`, I'm not quite sure how the issue
 arrises:

 {{{
 def gettext(message):
 return message


 gettext_noop = gettext_lazy = _ = gettext
 }}}

 Here `gettext_lazy` (and `_`) don't actually use `lazy`, so I'm not 100%
 sure how the equivalent line from the report comes up:

 {{{
 gettext_lazy_noop = lazy(gettext_noop, str)
 }}}

 However, you've hit it in the wild, so I must presume it does 🤔

 I wonder if forcing a string from `gettext()` in the the `trans_null` case
 makes sense?


 {{{
 diff --git a/django/utils/translation/trans_null.py
 b/django/utils/translation/trans_null.py
 index a687572b69..f590ff23cd 100644
 --- a/django/utils/translation/trans_null.py
 +++ b/django/utils/translation/trans_null.py
 @@ -6,7 +6,7 @@ from django.conf import settings


  def gettext(message):
 -return message
 +return str(message)


  gettext_noop = gettext_lazy = _ = gettext
 }}}

 Resolves the reported issue but I don't know if it would have other
 consequences.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7b4bf753865a053f23ba5cc483629023%40djangoproject.com.

Re: [Django] #32292: Allow postgresql database connections to use postgres services

[Django]

#32292: Allow postgresql database connections to use postgres services
-+-
 Reporter:  levihb   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  postgres service pg_service|
  config |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Configuration without `NAME` already works for me, e.g.:
 {{{
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {
 'service': 'default_django_test'
 }
 },
 }}}
 so only setting `PGSERVICE` for
 
[https://github.com/django/django/blob/2a76f4313423a3b91caade4fce71790630ef9152/django/db/backends/postgresql/client.py#L10-L44
 the underlying command-line client] and docs are missing.

 > I don't mind creating a pull request for it, but would like to know why
 it hasn't been added, ...

 Because you're the first to suggest it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.8cf4db3dd87ac1e6305ed42b54f07e37%40djangoproject.com.

Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * needs_better_patch:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.80f338be6ffb8faf8be4b7749ff92dbc%40djangoproject.com.

Re: [Django] #32292: Allow postgresql database connections to use postgres services

[Django]

#32292: Allow postgresql database connections to use postgres services
-+-
 Reporter:  levihb   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:
  postgres service pg_service|  Unreviewed
  config |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by levihb:

Old description:

> Postgres offers a way to make database connections through the use of
> services, which are basically equivalent to MySQL's options files.
>
> Server, database, username, etc information is stored by default in
> `~/.pg_service.confg` and takes a very similar format to MySQL cnf files:
>
> {{{#!python
> [my_alias]
> host=10.0.19.10
> user=postgres
> dbname=postgres
> port=5432
> }}}
>
> And password can be stored in `~/.pgpass` under a different format.
>
> I think being able to just add them to the DATABASES config would be
> useful, similar to how you can add MySQL cnf files. psycopg2 supports it
> just fine through the service argument/string
> `connect(service='my_alias') connect('service=my_alias')`.
>
> At the moment it can be added like this:
>
> {{{#!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'NAME': 'postgres',
> 'OPTIONS': {'service': 'my_alias'}
> }
> }
> }}}
>
> Which works, however it involves repeating the database name. I don't
> think the database name should be repeated twice because it couples the
> config and the service file together, and makes it harder to just move it
> between different environments. I think ideally you would just specify
> the service, either like this:
>
> {{{#!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'OPTIONS': {'service': 'my_alias'}
> }
> }
> }}}
>
> Or maybe a better way would be?:
>
> {{{#!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'SERVICE': 'my_alias
> }
> }
> }}}
>
> It seems like something that would be super easy to add. I don't mind
> creating a pull request for it, but would like  to know why it hasn't
> been added, and how it would be recommended to add it.

New description:

 Postgres offers a way to make database connections through the use of
 services, which are basically equivalent to MySQL's options files.

 Server, database, username, etc information is stored by default in
 `~/.pg_service.conf` and takes a very similar format to MySQL cnf files:

 {{{#!python
 [my_alias]
 host=10.0.19.10
 user=postgres
 dbname=postgres
 port=5432
 }}}

 And password can be stored in `~/.pgpass` under a different format.

 I think being able to just add them to the DATABASES config would be
 useful, similar to how you can add MySQL cnf files. psycopg2 supports it
 just fine through the service argument/string `connect(service='my_alias')
 connect('service=my_alias')`.

 At the moment it can be added like this:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'postgres',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 }}}

 Which works, however it involves repeating the database name. I don't
 think the database name should be repeated twice because it couples the
 config and the service file together, and makes it harder to just move it
 between different environments. I think ideally you would just specify the
 service, either like this:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 }}}

 Or maybe a better way would be?:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'SERVICE': 'my_alias
 }
 }
 }}}

 It seems like something that would be super easy to add. I don't mind
 creating a pull request for it, but would like  to know why it hasn't been
 added, and how it would be recommended to add it.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegrou

Re: [Django] #32292: Allow postgresql database connections to use postgres services

[Django]

#32292: Allow postgresql database connections to use postgres services
-+-
 Reporter:  levihb   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:
  postgres service pg_service|  Unreviewed
  config |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by levihb:

Old description:

> Postgres offers a way to make database connections through the use of
> services, which are basically equivalent to MySQL's options files.
>
> Server, database, username, etc information is stored by default in
> `~/.pg_service.confg` and takes a very similar format to MySQL cnf files:
>
> ```
> [my_alias]
> host=10.0.19.10
> user=postgres
> dbname=postgres
> port=5432
> ```
>
> And password can be stored in `~/.pgpass` under a different format.
>
> I think being able to just add them to the DATABASES config would be
> useful, similar to how you can add MySQL cnf files. psycopg2 supports it
> just fine through the service argument/string
> `connect(service='my_alias') connect('service=my_alias')`.
>
> At the moment it can be added like this:
>
> {{{#!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'NAME': 'postgres',
> 'OPTIONS': {'service': 'my_alias'}
> }
> }
> }}}
>
> Which works, however it involves repeating the database name. I don't
> think the database name should be repeated twice because it couples the
> config and the service file together, and makes it harder to just move it
> between different environments. I think ideally you would just specify
> the service, either like this:
>
> {{{#!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'OPTIONS': {'service': 'my_alias'}
> }
> }
> }}}
>
> Or maybe a better way would be?:
>
> {{{#!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'SERVICE': 'my_alias
> }
> }
> }}}
>
> It seems like something that would be super easy to add. I don't mind
> creating a pull request for it, but would like  to know why it hasn't
> been added, and how it would be recommended to add it.

New description:

 Postgres offers a way to make database connections through the use of
 services, which are basically equivalent to MySQL's options files.

 Server, database, username, etc information is stored by default in
 `~/.pg_service.confg` and takes a very similar format to MySQL cnf files:

 {{{#!python
 [my_alias]
 host=10.0.19.10
 user=postgres
 dbname=postgres
 port=5432
 }}}

 And password can be stored in `~/.pgpass` under a different format.

 I think being able to just add them to the DATABASES config would be
 useful, similar to how you can add MySQL cnf files. psycopg2 supports it
 just fine through the service argument/string `connect(service='my_alias')
 connect('service=my_alias')`.

 At the moment it can be added like this:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'postgres',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 }}}

 Which works, however it involves repeating the database name. I don't
 think the database name should be repeated twice because it couples the
 config and the service file together, and makes it harder to just move it
 between different environments. I think ideally you would just specify the
 service, either like this:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 }}}

 Or maybe a better way would be?:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'SERVICE': 'my_alias
 }
 }
 }}}

 It seems like something that would be super easy to add. I don't mind
 creating a pull request for it, but would like  to know why it hasn't been
 added, and how it would be recommended to add it.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.

Re: [Django] #32292: Allow postgresql database connections to use postgres services

[Django]

#32292: Allow postgresql database connections to use postgres services
-+-
 Reporter:  levihb   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:
  postgres service pg_service|  Unreviewed
  config |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by levihb:

Old description:

> Postgres offers a way to make database connections through the use of
> services, which are basically equivalent to MySQL's options files.
>
> Server, database, username, etc information is stored by default in
> `~/.pg_service.confg` and takes a very similar format to MySQL cnf files:
>
> ```
> [my_alias]
> host=10.0.19.10
> user=postgres
> dbname=postgres
> port=5432
> ```
>
> And password can be stored in `~/.pgpass` under a different format.
>
> I think being able to just add them to the DATABASES config would be
> useful, similar to how you can add MySQL cnf files. psycopg2 supports it
> just fine through the service argument/string
> `connect(service='my_alias') connect('service=my_alias')`.
>
> At the moment it can be added like this:
>
> ```
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'NAME': 'postgres',
> 'OPTIONS': {'service': 'my_alias'}
> }
> }
> ```
>
> Which works, however it involves repeating the database name. I don't
> think the database name should be repeated twice because it couples the
> config and the service file together, and makes it harder to just move it
> between different environments. I think ideally you would just specify
> the service, either like this:
>
> ```
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'OPTIONS': {'service': 'my_alias'}
> }
> }
> ```
>
> Or maybe a better way would be?:
>
> ```
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.postgresql',
> 'SERVICE': 'my_alias
> }
> }
> ```
>
> It seems like something that would be super easy to add. I don't mind
> creating a pull request for it, but would like  to know why it hasn't
> been added, and how it would be recommended to add it.

New description:

 Postgres offers a way to make database connections through the use of
 services, which are basically equivalent to MySQL's options files.

 Server, database, username, etc information is stored by default in
 `~/.pg_service.confg` and takes a very similar format to MySQL cnf files:

 ```
 [my_alias]
 host=10.0.19.10
 user=postgres
 dbname=postgres
 port=5432
 ```

 And password can be stored in `~/.pgpass` under a different format.

 I think being able to just add them to the DATABASES config would be
 useful, similar to how you can add MySQL cnf files. psycopg2 supports it
 just fine through the service argument/string `connect(service='my_alias')
 connect('service=my_alias')`.

 At the moment it can be added like this:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'postgres',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 }}}

 Which works, however it involves repeating the database name. I don't
 think the database name should be repeated twice because it couples the
 config and the service file together, and makes it harder to just move it
 between different environments. I think ideally you would just specify the
 service, either like this:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 }}}

 Or maybe a better way would be?:

 {{{#!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'SERVICE': 'my_alias
 }
 }
 }}}

 It seems like something that would be super easy to add. I don't mind
 creating a pull request for it, but would like  to know why it hasn't been
 added, and how it would be recommended to add it.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the 

[Django] #32292: Allow postgresql database connections to use postgres services

[Django]

#32292: Allow postgresql database connections to use postgres services
-+-
   Reporter:  levihb |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  3.1
  layer (models, ORM)|   Keywords:  database postgresql
   Severity:  Normal |  postgres service pg_service config
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Postgres offers a way to make database connections through the use of
 services, which are basically equivalent to MySQL's options files.

 Server, database, username, etc information is stored by default in
 `~/.pg_service.confg` and takes a very similar format to MySQL cnf files:

 ```
 [my_alias]
 host=10.0.19.10
 user=postgres
 dbname=postgres
 port=5432
 ```

 And password can be stored in `~/.pgpass` under a different format.

 I think being able to just add them to the DATABASES config would be
 useful, similar to how you can add MySQL cnf files. psycopg2 supports it
 just fine through the service argument/string `connect(service='my_alias')
 connect('service=my_alias')`.

 At the moment it can be added like this:

 ```
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': 'postgres',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 ```

 Which works, however it involves repeating the database name. I don't
 think the database name should be repeated twice because it couples the
 config and the service file together, and makes it harder to just move it
 between different environments. I think ideally you would just specify the
 service, either like this:

 ```
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'OPTIONS': {'service': 'my_alias'}
 }
 }
 ```

 Or maybe a better way would be?:

 ```
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'SERVICE': 'my_alias
 }
 }
 ```

 It seems like something that would be super easy to add. I don't mind
 creating a pull request for it, but would like  to know why it hasn't been
 added, and how it would be recommended to add it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.57a2c80a6b025a3e44bdb54e3871ad24%40djangoproject.com.

Re: [Django] #32290: TemplateNotFound if relative path passed to {% include %} in variable

[Django]

#32290: TemplateNotFound if relative path passed to {% include %} in variable
-+
 Reporter:  Peter Inglesby   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Template system
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report, it works for `{% extends %}` but raises
 `TemplateDoesNotExist` for `{% include %}` (see attached tests).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0c78f93fbfd72a06f668aa364f5db2ee%40djangoproject.com.

Re: [Django] #32290: TemplateNotFound if relative path passed to {% include %} in variable

[Django]

#32290: TemplateNotFound if relative path passed to {% include %} in variable
+--
 Reporter:  Peter Inglesby  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  3.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Mariusz Felisiak):

 * Attachment "ticket_32290_tests.diff" added.


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ec8c175550e5ad3da5f42adc3476d58d%40djangoproject.com.

Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13796 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.6923e963b76783adac66a9688953497a%40djangoproject.com.

Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:4 Federico Capoano]:
 > Have you already tried to create a new django app, put a dot in the
 app_label field of the AppConfig, ensure the AppConfig is mentioned in the
 __init__.py, then create a model and run ./manage.py makemigrations?

 Yes. Can you share a stacktrace? I'm not even sure in which line or file
 you encountered this issue 🤔

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.2fd842f1b773d1abcdbb2d66a1d6f8ec%40djangoproject.com.

Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Federico Capoano):

 Have you already tried to create a new django app, put a dot in the
 app_label field of the AppConfig, ensure the AppConfig is mentioned in the
 __init__.py, then create a model and run ./manage.py makemigrations?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.42c84bd7c4091f5f54c09a1565c54e92%40djangoproject.com.

Re: [Django] #32291: Add support for fixtures compression in dumpdata

[Django]

#32291: Add support for fixtures compression in dumpdata
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fixtures | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * stage:  Unreviewed => Accepted


Comment:

 This seems reasonable to me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1a202f7d4fe6fa607d0182b086912b89%40djangoproject.com.

Re: [Django] #32291: Add support for fixtures compression in dumpdata

[Django]

#32291: Add support for fixtures compression in dumpdata
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fixtures | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paolo Melchiorre):

 * cc: Paolo Melchiorre (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c94ba83f30f1d351b99485d80102e885%40djangoproject.com.

Re: [Django] #32291: Add support for fixtures compression in dumpdata

[Django]

#32291: Add support for fixtures compression in dumpdata
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fixtures | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paolo Melchiorre):

 * owner:  nobody => Paolo Melchiorre
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.15110d3dc709dcb2e659d22e44305583%40djangoproject.com.

Re: [Django] #32291: Add support for fixtures compression in dumpdata

[Django]

#32291: Add support for fixtures compression in dumpdata
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fixtures | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paolo Melchiorre):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/13797

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.697c6d2de67d5d3f9c68f2327d9b4b0e%40djangoproject.com.

[Django] #32291: Add support for fixtures compression in dumpdata

[Django]

#32291: Add support for fixtures compression in dumpdata
-+-
   Reporter:  Paolo  |  Owner:  nobody
  Melchiorre |
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  master
  (Management commands)  |
   Severity:  Normal |   Keywords:  fixtures
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Since `loaddata` command support compressed fixtures [1] loading, I would
 propose to add fixtures compression support in `dumpdata` command.

 [1] https://docs.djangoproject.com/en/dev/ref/django-admin/#compressed-
 fixtures

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.58106d84de4de7fe9762e424d74680a6%40djangoproject.com.

Re: [Django] #32285: AppConfig.label should raise an exception when it's not a valid Python identifier.

[Django]

#32285: AppConfig.label should raise an exception when it's not a valid Python
identifier.
-+-
 Reporter:  Federico Capoano |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.9ed64fb0de68fd5241180cac030f16d3%40djangoproject.com.

Re: [Django] #32289: Multi Theme support for the Admin

[Django]

#32289: Multi Theme support for the Admin
---+--
 Reporter:  Ramez Issac|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 If you need/want to change all templates, then you shouldn't use
 `django.contrib.admin` but rather prepare your own admin interface. I
 don't think that we would like to support such an extensive customization.
 You can start a discussion on DevelopersMailingList (where you'll reach a
 wider audience) if you don't agree.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.c51466285980b42d939538c082fc6ba7%40djangoproject.com.

Re: [Django] #32289: Multi Theme support for the Admin

[Django]

#32289: Multi Theme support for the Admin
---+--
 Reporter:  Ramez Issac|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Ramez Issac):

 * status:  closed => new
 * resolution:  duplicate =>


Comment:

 I don't think it qualifies as  a duplicate .

 By "theme" i mean a complete HTML structure (not just the colors as
 #32018 aims) and there is currently no way to have this HTML structure
 unique per AdminSite.. and that's what this ticket is about adding.

 Replying on Changing the app index and the index template:
 This is not the same a new theme.. because clicking on any admin link
 inside those "edited pages" would mean either 1.going back to the default
 theme for that clicked link or 2. that those ModelAdmin templates were
 explicitly set as well.

 I hope i made the ticket clearer.

 Thanks

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8f7552f6e24940c44ed913c64a0c26fe%40djangoproject.com.

[Django] #32290: TemplateNotFound if relative path passed to {% include %} in variable

[Django]

#32290: TemplateNotFound if relative path passed to {% include %} in variable
--+
   Reporter:  Peter Inglesby  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  3.1
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 If you pass a template path as string literal to `{% include %}`, the
 template path can begin with eg `./`, which is then resolved.

 However, if you pass a template path in a variable to `{% include %}`, the
 `./` is not resolved and Django raises `TemplateNotFound`.

 For instance, I have a template for rendering Bootstrap tab panels:

 {{{
 
   {% include template_path %}
 
 }}}

 This works:

 {{{
 {% include "./_bootstrap_panel.html" with tab_name="search-results"
 template_name="myapp/_search_results.html" %}
 }}}

 This doesn't:

 {{{
 {% include "./_bootstrap_panel.html" with tab_name="search-results"
 template_name="./_search_results.html" %}
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.55220c21f3e67da2c139c71d53e235f8%40djangoproject.com.

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

[Django]

#32269: parse_duration() ISO string sign is ignored when the timedelta only has
days
---+-
 Reporter:  Hanno  |Owner:  starryrbs
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  3.1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Ready for checkin
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"2a76f4313423a3b91caade4fce71790630ef9152" 2a76f43]:
 {{{
 #!CommitTicketReference repository=""
 revision="2a76f4313423a3b91caade4fce71790630ef9152"
 Fixed #32269 -- Fixed parse_duration() for negative days in ISO 8601
 format.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.547ce9dc9a27b946b734ac54f45c3c31%40djangoproject.com.

Re: [Django] #32289: Multi Theme support for the Admin

[Django]

#32289: Multi Theme support for the Admin
---+--
 Reporter:  Ramez Issac|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 You can use
 
[https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#django.contrib.admin.AdminSite.index_template
 
AdminSite.index_template]/[https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#django.contrib.admin.AdminSite.app_index_template
 app_index_template] and override CSS to use different theme for each admin
 site. Also with #32018 changing a theme will be much simpler. I think we
 can close it as a duplicate of #32018.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8a92e97aec8e84f4e9134dc7c3acdb28%40djangoproject.com.

[Django] #32289: Multi Theme support for the Admin

[Django]

#32289: Multi Theme support for the Admin
-+
   Reporter:  Ramez Issac|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  3.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 **Issue**:
 There is no way to mix between several admin themes.
 Say i installed a 3rd party admin theme and i want to use it along with
 the default (or with another 3rd party theme)

 While we can have many different admin sites, all admin sites currently
 must share the same theme.
 Because the admin assumes the template directory 'admin' all the time.


 **Proposal**:
 A way to direct each AdminSite to the template path where it should find
 the templates.


 **Example**:
 Add a setting called `ADMIN_DEFAULT_THEME = 'admin'`
 Add an attribute to AdminSite called `theme` which default to
 `ADMIN_DEFAULT_THEME`,  and basically this setting controls which
 directory this admin site looks for templates.

 So whenever a path like 'admin/some_file_name.html' occurs, it is to be
 replaced with something like
 `f'{admin_theme}/some_file_name.html'`
 This will take effect in extends statements, AdminSite templates
 loading(index/app index / etc) and ModelAdmin template loading (change
 form/list/delete etc..)

 If accepted then i'd love to start working on it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.e4683356c04014036c301ab3a607e5ee%40djangoproject.com.

Re: [Django] #32231: It should be possible to pass None as params for Model.objects.raw

[Django]

#32231: It should be possible to pass None as params for Model.objects.raw
-+-
 Reporter:  Alexander Lyabah |Owner:  Alexander
 |  Lyabah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  raw, psycopg2,   | Triage Stage:  Accepted
  execute, orm, db   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.f24be897877c2eff78f4861f5ac7b5a4%40djangoproject.com.

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

[Django]

#32269: parse_duration() ISO string sign is ignored when the timedelta only has
days
---+-
 Reporter:  Hanno  |Owner:  starryrbs
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Ready for checkin
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Mariusz Felisiak):

 * owner:  Hanno => starryrbs
 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/13791 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.90304f64a92c6eb0039bd209bb092b80%40djangoproject.com.

Re: [Django] #32208: add filter is unable to concatenate strings with lazy string

[Django]

#32208: add filter is unable to concatenate strings with lazy string
-+-
 Reporter:  Claude Paroz |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"577f2338f16bea055abc49c5a43fa3ecb05dffc8" 577f2338]:
 {{{
 #!CommitTicketReference repository=""
 revision="577f2338f16bea055abc49c5a43fa3ecb05dffc8"
 Fixed #32208 -- Allowed adding lazy() objects.

 Co-authored-by: Claude Paroz 
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.355189efa9fe8dc8f33d9fe601df2f88%40djangoproject.com.