Re: Fellow Reports -- June 2019
Hi all, Calendar Week 24 -- ending 16 June. Triaged: https://code.djangoproject.com/ticket/30566 -- Unable to do key lookup when a key is a number on PostgreSQL JSONB field (wontfix) https://code.djangoproject.com/ticket/30527 -- Problem with creating migrations for subclassed field changes. (Invalid) https://code.djangoproject.com/ticket/30207 -- Optimise paginator for tables with massive records (Needsinfo) https://code.djangoproject.com/ticket/30554 -- Excessive logging by autoreload in v 2.2.1 and 2.2.2 (Invalid) Reviewed: https://code.djangoproject.com/ticket/12952 -- Models history doesnt use verbose names https://code.djangoproject.com/ticket/30066 -- UserManager.create_superuser doesnt allow for omitting email or password, unlike create_user which does. https://code.djangoproject.com/ticket/30547 -- Document what happens during model validation with Meta.constraints. https://github.com/django/django/pull/11209 -- Fixed #30451 -- Implemented ASGI handler and coroutine-safety. https://github.com/django/django/pull/11417 -- Fixed #30512 -- Used email.headerregistry.parser for parsing emails in sanitize_address(). https://github.com/django/django/pull/10910 -- Fixed #30128 -- Fixed handling timedelta timezone in database functions. https://code.djangoproject.com/ticket/30128 -- Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query https://github.com/django/django/pull/11468 -- Added missing support for PointOnSurface function on MariaDB. https://code.djangoproject.com/ticket/30553 -- Misleading logging documentation about disable_existing_loggers default value. Authored: https://github.com/django/django/pull/11472 -- Refs #30512, #15042 -- Added local-only address to sanitize_email() tests cases. 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 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/a7a3121d-37eb-43b8-93ca-34463f61bf03%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Redis cache support in core
Hello, I would like to work on Redis support in core, and I would like to discuss proper solution for that. Redis is getting so popular and almost every modern backend stack uses it someway, therefore I think that supporting it as a cache backend in core would make Django more appealing. A solution I'm proposing is to extract base KV backend from current Memcached and extend it for both Memcached and Redis, and this won't add many new code to the core. Also we'll have base class for KV storage backends. 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/3a506133-f08a-4d25-a9c5-099aae3722d8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: django-cms migration issue on postgresql TypeError while migrating the models in postgresql
sure you found out, in the meantime...for others coming here: https://github.com/divio/django-cms/issues/ short: pin your psycopg2 version below 2.8. On Friday, 19 April 2019 10:37:36 UTC+2, Marutesh Maru wrote: > > `django-cms`: When i tried to perform `python manage.py migrate` in > postgresql, it is returning a `TypeError` but it is not giving any error in > `sqlite3`. > > This is my full traceback: > > File "manage.py", line 22, in > execute_from_command_line(sys.argv) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/core/management/__init__.py", > > line 364, in execute_from_command_line > utility.execute() > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/core/management/__init__.py", > > line 356, in execute > self.fetch_command(subcommand).run_from_argv(self.argv) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/core/management/base.py", > > line 283, in run_from_argv > self.execute(*args, **cmd_options) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/core/management/base.py", > > line 330, in execute > output = self.handle(*args, **options) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/core/management/commands/migrate.py", > > line 204, in handle > fake_initial=fake_initial, > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/db/migrations/executor.py", > > line 115, in migrate > state = self._migrate_all_forwards(state, plan, full_plan, > fake=fake, fake_initial=fake_initial) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/db/migrations/executor.py", > > line 145, in _migrate_all_forwards > state = self.apply_migration(state, migration, fake=fake, > fake_initial=fake_initial) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/db/migrations/executor.py", > > line 244, in apply_migration > state = migration.apply(state, schema_editor) > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/cms/migrations/0019_set_pagenode.py", > > line 68, in apply > > connection.introspection.get_table_description(connection.cursor(), > 'cms_page') > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/db/backends/postgresql/introspection.py", > > line 87, in get_table_description > )) for line in cursor.description > File > "/home/vagrant/.virtualenvs/pmvp/lib/python3.6/site-packages/django/db/backends/postgresql/introspection.py", > > line 87, in > )) for line in cursor.description > TypeError: sequence index must be integer, not 'slice' > > Can anyone help me out? > -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to django-cms-developers+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-developers+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/718e7c57-6196-418b-bc34-b7a795adbb59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: GDAPS
On 6/17/19 5:47 PM, Christian González wrote: I've given some thought to this over the years, and what I think we've somehow missed in settings until now is ... Namespaces! I can second this from my POV, having "evaluated" a few plugin systems now. Any plugin or app ought be able to declare its own settings and their defaults. And ISTM the "obvious" place to do this is in their AppConfig Except, that may be too late, since we may want/need the settings before apps are loaded? So the alternative is for a plugin to declare in its entry points a reference to its settings declaration. This way, all 3rd party settings can be gathered, vetted, and applied before having to scan the INSTALLED_APPS list. I want to separate these things: Yes, AppConfig is too late, as the settings.py is already scanned, and INSTALLED_APPS are determined. That's because Django works this way. I don't recommend Django to completely change its way of loading apps. In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via setuptools entry point, like pretix. I therefore added my Pluginmanager hook, also like pretix. It just finds the plugins and adds them to INSTALLED_APPS. But here it is too late. settings.py continues, and *afterwords* all the apps are scanned for their settings. you can't override them again in settings.py after that. I'm a little unclear here. Is it too late because you want to be able to exclude settings from packages that are installed but you don't want "active" in the project? That you only want 3rd party "settings contributing" plugins to be activated when selected? In which case, doesn't it make more sense to include a plugins.cfg to be processed _before_ settings.py to decide? And if handled well, I expect only an exclusion list may be required [but an inclusion list would be safer]. What would IMHO clean this problem, would be moving INSTALLED_APPS outside of settings.py (maybe in a declarative way: yml, cfg file etc.). Then Django could scan this list, load apps (or do whatever it needs, scan metadata, check for compatibility, etc.), load their settings, and *afterwords* run the main settings.py to eventually override some of the apps' settings globally. This could even be coded with backwards compatibility, e.g. if installed_apps.cfg is present, use that (and disallow INSTALLED_APPS in settings.py), else fall back to settings.INSTALLED_APPS. It wouldn't be necessary to make a setuptools entry point for app/plugin settings. The entry point I would recommend is a "settings.py" for each app - automatically namespaced or better, with a NAMESPACE = "fooplugin" - which would enable having 2 plugins using the same namespace (think of "sub-plugins" of one bigger plugin). Ah, I think I see now. You want INSTALLED_APPS to be the definitive truth of all apps _and_ plugins. So it's not possible to have a plugin that's not also an app? Sub-plugins opens up the can of works that is dependency resolution. Now what we'll need is a way to avoid namespace clashes, and a dev-friendly way to update these settings in settings.py I would definitely *allow* namespace clashes, as explained above. Like in partial classes. A "Textprinter" plugin could have 3rdparty sub-plugins, which could use the same namespace (HTMLProviderPlugin, MarkdownProviderPlugin etc.) Yes, I did consider this. I think it's valid that a plugin may override another plugins defaults. But in the end, the projects settings.py should be final. -- Curtis -- 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/6e74db34-c879-f2d3-89ac-88df9d03804c%40tinbrain.net. For more options, visit https://groups.google.com/d/optout.
Re: GDAPS
> I've given some thought to this over the years, and what I think we've > somehow missed in settings until now is ... Namespaces! I can second this from my POV, having "evaluated" a few plugin systems now. > Any plugin or app ought be able to declare its own settings and their > defaults. And ISTM the "obvious" place to do this is in their AppConfig > > Except, that may be too late, since we may want/need the settings > before apps are loaded? > > So the alternative is for a plugin to declare in its entry points a > reference to its settings declaration. This way, all 3rd party > settings can be gathered, vetted, and applied before having to scan > the INSTALLED_APPS list. I want to separate these things: Yes, AppConfig is too late, as the settings.py is already scanned, and INSTALLED_APPS are determined. That's because Django works this way. I don't recommend Django to completely change its way of loading apps. In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via setuptools entry point, like pretix. I therefore added my Pluginmanager hook, also like pretix. It just finds the plugins and adds them to INSTALLED_APPS. But here it is too late. settings.py continues, and *afterwords* all the apps are scanned for their settings. you can't override them again in settings.py after that. What would IMHO clean this problem, would be moving INSTALLED_APPS outside of settings.py (maybe in a declarative way: yml, cfg file etc.). Then Django could scan this list, load apps (or do whatever it needs, scan metadata, check for compatibility, etc.), load their settings, and *afterwords* run the main settings.py to eventually override some of the apps' settings globally. This could even be coded with backwards compatibility, e.g. if installed_apps.cfg is present, use that (and disallow INSTALLED_APPS in settings.py), else fall back to settings.INSTALLED_APPS. It wouldn't be necessary to make a setuptools entry point for app/plugin settings. The entry point I would recommend is a "settings.py" for each app - automatically namespaced or better, with a NAMESPACE = "fooplugin" - which would enable having 2 plugins using the same namespace (think of "sub-plugins" of one bigger plugin). > Now what we'll need is a way to avoid namespace clashes, and a > dev-friendly way to update these settings in settings.py I would definitely *allow* namespace clashes, as explained above. Like in partial classes. A "Textprinter" plugin could have 3rdparty sub-plugins, which could use the same namespace (HTMLProviderPlugin, MarkdownProviderPlugin etc.) -- 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/20bd7071-5149-f5e8-86cb-1497d83fc665%40nerdocs.at. For more options, visit https://groups.google.com/d/optout. pEpkey.asc Description: application/pgp-keys
