Re: Proposal to add a flatten() to django.utils

Hi David, I think, I'm in support for a django.utilsflatten() function with the requirements / constraints you outlined below. Cheers, Markus On Mon, Oct 17, 2022, at 8:31 AM, David Sanders wrote: > Hi folks, > > As part of PR 16175 there was

Re: Add ability to show the migration plan (#23359)

liked it on migrate. >> >> I don't really mind which way you go, to be honest; both seem like >> sensible places. Other people might have stronger opinions. >> >> Andrew >> >> On Wed, Oct 29, 2014 at 4:44 PM, Markus Holtermann < >> in...@

Make deconstructible classes forwards compatible

Hi all, As of now (Django 1.7.x and master) the migration writer serializes classes like the CreateModel operation with kwargs and not args. Which is the right way to do. However, as soon as Django changes some of these operations' constructor signatures (as I plan to do in https://code.djangop

Re: Make deconstructible classes forwards compatible

Hey Carl, On Friday, November 21, 2014 7:57:47 PM UTC+1, Carl Meyer wrote: > > Hi Markus, > > On 11/21/2014 05:35 AM, Markus Holtermann wrote: > > As of now (Django 1.7.x and master) the migration writer serializes > > classes like the CreateModel operation with kwargs

Re: Infinite loop in migration code

Hey Luke, It would be interesting to see why A.1 and B.1 depend on each other. If there are e.g. FK constraints pointing to models in the other app the autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 (or optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up with a

Re: Infinite loop in migration code

hat shouldn't happen. /Markus On Wednesday, November 26, 2014 8:54:55 AM UTC+1, Luke Plant wrote: > > On 25/11/14 16:23, Markus Holtermann wrote: > > Hey Luke, > > > > It would be interesting to see why A.1 and B.1 depend on each other. If > > there are e.g.

Re: does django-admin need a man page?

On Wednesday, November 26, 2014 7:46:16 AM UTC+1, Aymeric Augustin wrote: > > Le 26 nov. 2014 à 01:51, Nick Phillips > a écrit : > > > > I'd suggest considering implementing > > something to generate a man page from whatever you wish the "canonical" > > source of the information to be. > > Th

Re: Infinite loop in migration code

> user = FK(auth.User) > > > = > > I ran makemigrations for 'camps', then 'officers', and the generated > migrations ended up depending on each other. > > Hopefully that's enough, let me know if that doesn't reproduce it. >

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

Hey folks, I don't like the idea of expected failures either. Given the fact that at one point user defined indexes are going to be introduced, I would consider to delay this issue for now until the DEP has been accepted and is (being) implemented. At that point we know what the underlying API

Adding model managers to migrations

Ticket: https://code.djangoproject.com/ticket/23822 Pull Request: https://github.com/django/django/pull/3687 Hey folks, As of now migrations don't expose the model managers to models. Thus it is "impossible" to use e.g. `create_superuser` in a `RunPython` operation. I opened ticket #23822 to ke

Re: Bypassing 1.7+ migrations

Hey Marcin, Andrew, setting manager=False wouldn't work either, as the migrations for those models still need to exist. I probably have references to them which makes them a requirement for FKs in migrations. Unmanaged models behave exactly the same as managed models in migrations, with one exc

Re: #23996 Allow AlterOrderWithRespectTo to order existing data

Hi Mike, Thanks for grabbing it. I'd suggest to wait for the patch for #23983 being merged and than work on the updated master branch. From my point of view, the pull-request shouldn't add this new feature, as it would be backported to 1.7 which isn't covered by the backporting guidelines. Thus

Re: Bypassing 1.7+ migrations

Hey Shai, manage=False won't gain you anything, since those models will still show up in migrations, because they need to be able to be referenced by managed models. The migration database operations are noops though. /Markus On Thu, Dec 18, 2014 at 06:08:52AM +0200, Shai Berger wrote: FWIW, t

Re: status of 1.8 release blockers

Hey Tim, thanks for the collection of tasks that have to be done for 1.8. Especially wrt #23861 and #23891 I just realized that, since 1.8 is an LTS release, we'd need to support and that field (and related changes) until 2018. That's Django 2.2/2.3 I guess. Considering the ideas that exists to

Re: Delivering PR 3114 - The _meta refactor

Hey folks, On Monday, December 22, 2014 3:29:15 PM UTC+1, Aymeric Augustin wrote: > > Hi Russell, > > 2014-12-22 8:39 GMT+01:00 Russell Keith-Magee >: > >> The question: Do we - >> >> 1) Accept this particular internal specific naming of GFK as a quirk >> reflecting the limitations of contrib.a

Re: status of 1.8 release blockers

On Monday, December 29, 2014 10:40:06 AM UTC+1, Claude Paroz wrote: > > On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote: >> >> #23745 - Migrations migrate is slow >> (new) >> Owner: Claude >> Status: Patch seems to need improvement so

Re: QuerySet.as_manager doesn't offer a way to use_for_related_fields

Hey Martin, To solve the problem I can think of two reasonable solutions: class MyManager(models.Manager.from_queryset(MyQuerySet)): use_for_related_fields = True or class MyModel(models.Model): objects = MyQuerySet.as_manager() objects.use_for_related_fields = True After all, as_m

Replace decimal prefix(kB) with binary prefix (KiB) for bytes

Hey folks, I saw that the Django docs currently use file size units kB, MB, etc. that refer to a multiple of 1000 (1000, 100 bytes respectively -- https://docs.djangoproject.com/en/dev/ref/settings/#file-upload-max-memory-size ). But the numbers actually are to the power of 1024. To remedy inc

Re: Keeping apps without migrations?

Creating in-memory migrations for all apps that don't have migration files seems to be an option to solve the dependency problem. This would even allow apps without migrations to depend on those with migrations. We have to consider though, that there are tens of apps and hundreds of models in our

Re: Must a Django Database Support Migrations?

Hey, as soon as the MigrationRecorder is used there is a call to "ensure_schema" that forces the creation of the migration table. The runserver command (among others?) checks for unapplied migrations and thus creates the migration table. /Markus On Wednesday, January 21, 2015 at 12:36:47 AM U

Usage of field cardinality flags in database schema backends

Hey all, Since Django 1.8 (currently in alpha state), model fields gained cardinality flags as part of the _meta refactoring. So, there is one_to_one, one_to_many, many_to_one and many_to_many. These flags are currently only used inside user-facing APIs such as forms and the admin. Furthermo

Re: discontinue shipping tests with contrib apps?

I'm +1 on moving the contrib tests to tests/_tests/ . The respective ticket on Trac is https://code.djangoproject.com/ticket/24293 /Markus On Monday, February 9, 2015 at 4:09:47 PM UTC+1, Tim Graham wrote: > > I wonder if there is any need to continue to ship tests as part of contrib > apps? Cu

Re: status of 1.8 release blockers

Hey Tim, Thanks for the update. Could you check if #24282 is fixed by my PR as well and assign it to me in case it is. The error message looks familiar to the one I commented on the PR. Thanks. /Markus On February 13, 2015 2:33:38 AM GMT+01:00, Tim Graham wrote: >Status of release blockers:

Re: status of 1.8 release blockers

Hey folks, I looked into the issues #24225, #24264 and #24282 and have a working pull request ready for review: https://github.com/django/django/pull/4097 The essential change in the pull request is the way how the set of models that needs to be rerendered is constructed. Instead of naively onl

Re: status of 1.8 release blockers

Migrations > fail with unused swappable model > <https://code.djangoproject.com/ticket/24291> > Owner: Markus > Status: Patch looks good to me; Markus to review & commit tomorrow. > > On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote: >> >&g

Re: Support for DATABASES['default'] = {}

The question I'm asking myself right now: what is a "default" database in a multi database setup where "default" does not make sense at all? I can easily think of a case where I have multiple other databases used by other services where Django provides a dashboard. I don't see any of those data

Re: Composite fields

While I like your approach, Thomas, I should also note that I'm not an expert on those parts of Django and haven't kept up with the Michal's proposal. With respect to migrations I like Anssi's approach to have both `author` and `author_id` in _meta.fields. It will probably simplify a couple of

Re: django-admin.py shebang

Hi Stan, how did you install Django? As a system package via the system's package manager or via pip. If its the system package manager, please raise that bug in the bug tracker of your Linux distribution. If the answer is "via pip", from where? PyPI or something obscure? As Collin already wro

Re: 1.9 release planning

On Tuesday, April 7, 2015 at 1:21:20 AM UTC+2, Tim Graham wrote: > > With a 9 month schedule, here is what the future might look like: > > 1.8 - April 2015 > 1.9 - January 2016 > 2.0 - October 2016 > 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7 > since 3 years of LTS

Re: Newer version of Sqlite (3.8.9) breaks django -- should we backport

For reference, Tim just backported your patch to 1.7 and 1.8 . /Markus On Tuesday, April 14, 2015 at 5:25:28 PM UTC+2, Peter J.

Re: Must a Django Database Support Migrations?

t; table when an actual recording operation is done, and have it swallow >the >> table not existing as "no migrations applied" the rest of the time, >if >> people think that seems sensible. >> >> Andrew >> >> On Thu, Jan 22, 2015 at 10:44 AM, Marku

Re: virtual fields and the migration framework

Hey Federico, I just had a brief look at the code. If I understand the HStoreVirtualMixin.contribute_to_class() correctly and its implications regarding add_field(), I'd try to use cls._meta.add_field(self, virtual=True) instead of a simple cls._meta.add_field(self). That way the virtual field

Re: Idea/request for help: Django Developers Community Survey

It's an amazing idea. Thanks for putting it up, Aymeric and Tim! Can we add a question regarding usage of test frameworks (i.e., unittest2, py.test, nose) similar to "Which popular third-party apps do you rely on?" For example "Which test frameworks do you use?" - "unittest2, py.test, nose, oth

Re: Any Windows users who could help setting up Jenkins slaves?

Hey Tim, I haven't done it myself but if nobody else volunteers I'm up for the challenge. /Markus On Thursday, April 30, 2015 at 5:49:27 PM UTC+2, Tim Graham wrote: > > It would be nice to add Windows support to our continuous integration. Do > we have anyone with experience setting up Windows

Re: Capturing faked migrations in django_migrations table

Hi Steve, apart from what Tim said, since you commit the migration files as part of the apps' code to your source code version control system, you can simply have a look at the commit dates there. I'm not convinced having a marker for faked migrations in the database is useful. /Markus On Wed,

Re: Capturing faked migrations in django_migrations table

t;> > bug, but it's almost too conservative in that aspect. >> > >> > Are you manually faking these migrations? Or having Django do it for you >> > and getting it wrong? >> > >> > Andrew >> > >> > On Wed, May 13, 2015 at 10:2

Re: Deprecate internal syncdb in 1.9 ?

n the deprecation timeline was that syncdb used to use the old DDL code, this argument does not hold anymore. syncdb uses the same DDL code as migrations. /Markus On Wednesday, June 3, 2015 at 1:16:37 PM UTC+2, Andriy Sokolovskiy (coldmind) wrote: > > After discussion with Markus Holtermann, we d

Re: 1.9 release planning

Thanks Loic, that helps A LOT! I'm +1 on a semver or semver-ish policy. I don't have a favorite of the proposed. And I'm +-0 on changing e.g. 1.9 to 2.0 or whatever is required to match the new release policy. /Markus On Tue, Jun 16, 2015 at 02:15:59PM +0700, Loïc Bistuer wrote: I've attempted

Re: 1.9 release planning

+1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid plan. I don't think any of the (Pending)DeprecationWarnings are much of a public API. I've never seen them in the wild. /Markus On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: +1. I really don't like the idea o

Re: naming of a new test client method for logging in

I second Andriy's comment. /Markus On Tue, Jun 30, 2015 at 04:41:06PM +0300, Andriy Sokolovskiy wrote: force_login() seems to be more clear what it going on inside On 6/30/15 16:38, Tim Graham wrote: There's a proposal [1] to add a new method to the test client that works like login(), but sk

Re: metaclass expertise needed on migrations bug

Thanks for brining this to my attention, Tim! I just commented on the issue: https://code.djangoproject.com/ticket/25068#comment:12 /Markus On Thu, Jul 09, 2015 at 01:13:11PM -0700, Tim Graham wrote: To someone with experience with metaclasses, A high-level overview of this ticket/pull request

Re: Why Django is making migrations for external apps?

Hi all, While your proposal could solve the repeated creation of migrations due to dynamic choices, Simon, I don't see how it would solve or prevent the issue Carl mentioned earlier. Data migrations may need to have the exact choices at that particular state. Importing the current choices may f

Re: Simplifying MANIFEST.in

On Wed, Jul 22, 2015 at 09:40:08AM -0700, Tim Graham wrote: Lately we've had some packaging problems due to mistakes in MANIFEST.in, mostly due to missing files in the source distribution because we forgot to update MANIFEST.in for new or moved files. Currently it looks like this: include README

Re: Why Django is making migrations for external apps?

On Mon, Jul 20, 2015 at 11:56:40AM -0600, Carl Meyer wrote: On 07/20/2015 11:47 AM, Shai Berger wrote: On Monday 20 July 2015 18:47:07 Carl Meyer wrote: Personally I don't really see much use case for this feature except as a workaround for reusable apps that generate spurious new migrations

Re: Keeping apps without migrations?

reate empty migrations dir for any installed app without it https://code.djangoproject.com/ticket/24588 - Improve handling apps without migrations while running migrate command. On Sunday, January 18, 2015 at 5:11:53 PM UTC-5, Markus Holtermann wrote: Creating in-memory migrations for all apps t

Re: Django Admin New Look

Hey, Looking at some browser market share stats (http://www.sitepoint.com/browser-trends-august-2015-chrome-exceeds-50/ , disclaimer: http://www.sitepoint.com/how-browser-market-share-is-calculated/) IE8 seems hardly be used anyway. Furthermore, with the dropped support for IE8 (and 9+) on Jan 12

Re: Pre-DEP: community support of unmaintained versions of Django

Hey Christian, On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote: Regarding the version number, from what I've read, there's still a reported compatibility issue if we use the +localidentifer part of a version number with older versions of setuptools. I need to do some testing on

Re: Keeping apps without migrations?

django/core/management/commands/migrate.py >> @@ -133,7 +133,7 @@ class Command(BaseCommand): >> targets = executor.loader.graph.leaf_nodes() >> >> plan = executor.migration_plan(targets) >> - run_syncdb = options.get('run_syncdb') and >> executo

Re: Keeping apps without migrations?

ions mandatory. If you want to ditch > them > > and do your own database management, we should let you - which we could > do > > with some kind of MIGRATIONS_MODULES opt-out that basically sets > everything > > to pseudo-unmanaged, but I see no reason not to have the

Re: Ability to migrate other applications

Thank you for your patches and ideas of how to solve this feature, Emmanuelle. However, I strongly agree with Andrew that, if we allow this -- I'm on Tim's side here, it feels odd encouriging something that's not considered to be used for that purpose: `contribute_to_class` -- the solution shou

Re: Password validation in Django revisited

Hey, while I like the idea of having the validation in all places to not forget one that might be user facing, I was surprised by the fact that the validation also happens in dev environments when you create the superuser (this whole mail applies to the changepassword command, too): $ python m

Re: Password validation in Django revisited

rning and proceed > - or ask the user if they want to proceed with the invalid password > (--no-input would skip this step and proceed silently) > > -- > Aymeric. > > > > On 5 sept. 2015, at 01:56, Markus Holtermann > wrote: > > Hey, > > while I like the

Re: Ability to migrate other applications

On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote: > > > > On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek > wrote: > > > >> > >> The order of migrations isn't something which is local to this > >feature, it > >> is something which isn't fixed (probably by design,

Re: Capturing faked migrations in django_migrations table

Hey there, here's a pull request for this feature: https://github.com/django/django/pull/5279 . I'd appreciate some review. /Markus On Wednesday, May 20, 2015 at 9:25:00 AM UTC+10, steve byerly wrote: > > Awesome, thank you very much for the detailed answer. > -Steve > > On Tue, May 19, 2015 a

Re: Capturing faked migrations in django_migrations table

t could cause some weird behavior and confusion if not documented why it's set. Option 4, no idea, it sounds correct to me. /Markus On Sunday, September 13, 2015 at 10:08:15 AM UTC+10, Markus Holtermann wrote: > > Hey there, > > here's a pull request for this feature: > http

Re: Feature Proposal: per-settings fake migration override

Hi Flavio, This sounds like a very risky and scary proposal, to be honest. The recommended way would indeed be to fake the initial migration(s) on production. Since it seems to me that this would only ever be needed once (you said devs should just run the migration locally and the table is too

Re: status of 1.9 release blockers

I did not fully follow the discussion, but by the amount of email notifications I got on that PR if feels to me that deferring it to 1.10 would be the better option, also considering what Tom said about this being part of a core component and it has to be done right. /Markus On Wednesday, Sept

Re: Non-atomic migrations in Django?

Hi Ludwig, the API looks clean and sensible to me. +1 for getting that into 1.10 /Markus On November 25, 2015 12:00:59 AM GMT+10:00, "Ludwig Hähne" wrote: >Hi all, > >I'd like to get your feedback on supporting non-atomic migrations in >Django. > >Database transactions are always wrapped in tr

Re: worth adding PyPy to continuous integration?

Hey Tim, I think we should at least run the tests occasionally and see if they pass and if not see how much effort it takes to fix problems. Regarding the migration date issues, I fixed them in newer PyPy versions: https://bitbucket.org/pypy/pypy/issues/2062/inconsistency-in-__repr__-for-date-t

Re: MOSS Award to Django

>From my point of view the major non-functional difference is the interaction >with a client in *some way*. While a celery task runs without any form of >client, a channels method would mostly do that. Picture the following example: A user uploads an image. This could happen through the common r

Re: MOSS Award to Django

On December 16, 2015 6:01:58 PM GMT+10:30, Shai Berger wrote: >On Wednesday 16 December 2015 08:08:59 Markus Holtermann wrote: >> From my point of view the major non-functional difference is the >> interaction with a client in *some way*. While a celery task runs >without >

Re: Removing Unique Together Field

Hey Bill, I added a patch for the ticket Tim already linked to. This solves the problem for RemoveField operations, RenameField shouldn't be a problem since the generation of AlterUniqueTogether and AlterIndexTogether are already based on renamed fields. Tests welcome ;) /Markus On Mon, Oct 27,

Re: sys.exit(1) from makemigrations if no changes found

I like the general idea, but I slightly disagree with "As the command is instructed to make migrations, not making any is the error case.". Yes, grep works that way but I thing this are two different use cases. I think makemigrations on a project without any changes in the models' database repr

Add ability to show the migration plan (#23359)

Hey folks, A few weeks ago I opened a ticket (https://code.djangoproject.com/ticket/23359) to add the ability to show a migration plan similar as listing all migrations within a project (manage.py migrate --list). After some discussions on IRC and on the first pull request (https://github.com/

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

Thanks for checking and asking! On Python 2, the email address with "i without dot" isn't a valid email address according to the EmailValidator and thus shouldn't be in your database in the first place. Cheers, /Markus On Wed, Dec 18, 2019, at 11:23 AM, Sam Willis wrote: > Hi, > > It looks

Re: New Merger nomination.

Thanks James for summarizing the process. Thanks Mariusz for the suggestion. Let's make it official, then. I'd like to nominate Claude Paroz (https://github.com/claudep) to be a Merger for the Django project and ask my fellow Technical Board members to cast their votes. Claude has been contribu

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

Makes sense. We'd have the deprecation shims around for a while anyway. /Markus On Tue, Mar 17, 2020, at 11:10 AM, Carlton Gibson wrote: > Ok, that’s pretty quick and conclusive, so let’s progress. Thanks all. > > On Tue, 17 Mar 2020 at 11:00, Shrawan Poudel wrote: > > +1 from me > > > > On T

Re: Technical Board statement on type hints for Django

Thanks for pushing this public, Adam. In the discussion I brought up these points. I've been using static typing in Python for about 1.5 years now. Every now and then it's neat, but often enough I get annoyed by it. Either because I simply don't know how to use the tools at hand correctly or be

Re: New Merger nomination.

I vote in favor of Claude becoming a MERGER. Cheers, Markus On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote: > I cast my vote in favor of Claude's nomination as well. > > Le jeudi 16 avril 2020 16:16:31 UTC-4, Adam Johnson a écrit : > > This has fallen by the wayside, let's try restarting. >

Re: Progress report: DEP 10 implementation

Thanks for the summary, James. As one of the IRC group contacts, here's the proposal for what happens to the cloaks on Freenode: - Right now there's a @django/committer/$name cloak. We'd abandon that cloak. - Instead, every DSF member can apply for a @django/member/$name cloak by getting in to

Re: Generate JWTs with Django

Nice work, Claude! However, dealing with JWTs, and especially verifying them is notoriously hard and fragile. Frankly, I think I'd rather see smaller libraries do one job and do it well, than having Django implement an incomplete JWT spec. As far as I can tell, only HS256 signing/verification i

Re: [FEATURE] Allow squashmigrations to squash the whole project

Have you considered to allow for multiple app_labels in the `squashmigrations` command, maybe together with a `--cross-app` flag, to specify the apps from which migrations should be squashed? That way we don't need to rely on paths at all, but can log up all migrations in question, based on the

Re: [FEATURE] Allow squashmigrations to squash the whole project

But for isort one specifies the `known_first_party` and `known_third_party` packages. https://github.com/timothycrosley/isort#configuring-isort At least I was under the impression that that's the only way how it decides where to place imports. Cheers, Markus On Tue, Apr 28, 2020, at 9:41 PM,

Re: Ticket #25236: Remove ifequal from the template language

Yes please! Nice catch and followup :) Cheers, Markus On Mon, May 4, 2020, at 4:08 PM, Jon Dufresne wrote: > Hi, > > I'd like to raise this topic for renewed discussion. I think it is time > to begin deprecating the obsolete template tags. So +1 for removal. > > I had all but forgotten about

Re: Django Version 3.2 Roadmap

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 re

Re: Clear all filters

I tend to agree with Adam. >From a UI/UX perspective, the location where the "Clear all filters" button >is, as well as the wording, suggest to me that it's only the filters on the >right side. The search query, while technically filtering the query set, >doesn't seem like a filter in the UI.

Re: What happens if a Fellow has a holiday?

Enjoy your time off. I'll keep my eyes open for PRs. Cheers, Markus On Thu, Jun 4, 2020, at 2:09 PM, charettes wrote: > Happy to review help as well. > > Enjoy your well deserved time off! > > Le jeudi 4 juin 2020 06:47:57 UTC-4, Carlton Gibson a écrit : > > Hi all. > > > > Short answer is w

Re: Unsolicited mentorship requests

Interesting. Because I got a similar messages this morning, one on Twitter and one on LinkedIn. Here's my response: > Hi {{ name }}. Thank you for reaching out. Unfortunately, I'm not available > for outside help at this time. If you need help working on Django projects > would like to suggest

Re: The blacklist / master issue

I'd be in favor of changing blacklist/whitelist into something that makes sense. In many cases, that's going to be context dependent, but often blocklist/allowlist will work. With regards to "master" as the development branch on GitHub, I'd like to pick whatever GitHub eventually goes with as a

Re: The blacklist / master issue

First things first: I'm glad, Django changed master/slave and blacklist/whitelist to more appropriate and adequate terms. Naming things is hard. And just because somebody came up with a name decades ago doesn't mean it can't — or even shouldn't — be changed. Especially when there are more descr

Re: f-strings again.

I've been one of those who previously were against adding them to Django. Mostly, because I wasn't used to them and didn't see their value. But more importantly, because I was worried about unintended security issues they could cause. Why the latter is still present, I've think the vulnerability

Re: Status of 3.1 release blockers.

Thank you for summarizing our IRC discussion, Mariusz. To be clear, the problem occurs during the upgrade process where more than 1 server is involved. That might be the case in small deployments with just 2 servers, where the time of two Django versions running simultaneously is likely small, o

Re: Status of 3.1 release blockers.

No, it won't move the problem to 3.2. The problem is that 3.0 only knows about sha1. 3.1 and later know about sha1 and sha256. Meaning, any >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. Cheers Markus On Fri, Jul 31, 2020, at 12:08 PM, Raffaele Salmaso wrote: > On F

Re: Status of 3.1 release blockers.

Can we come up with a way that we have the settings variable around for now, only to allow transitioning, and then add it as a proper feature in 3.2. As for the feature, I think we could choose a path like passlib does: A list of 2 (n>=1) algorithms. The first one will be used for signing, and a

Re: Set up autolinks on Django's GitHub repositories

Hi Sage, thank you for the suggestion. There's already autolinking setup for `ticket-123`. I'm happy to add another one which would be a bit briefer. But if this is done, the contribution documentation needs to be updated as well. /Markus On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com wrot

Re: Anonymous access to the forum

Thanks for bringing this up, Claude. I'll look into it. Cheers, Markus On Tue, Aug 18, 2020, at 9:14 AM, Claude Paroz wrote: > Hello, > > Am I the only one or did Google closed anonymous access to Google groups? > Could it be a setting in the group config? > > In my opinion, it is not acceptab

Re: Anonymous access to the forum

Thanks Adam. I did set the value to "Anyone on the web" again (it had that value already). And since that didn't change anything I went public: https://twitter.com/m_holtermann/status/1295635386820157440 What _does_ work, is viewing threads directly, only showing a list of threads doesn't work

Re: Technical Board Decision Needed: Admin append_slash behaviour.

Thanks you for bringing this up, Carlton. And thanks Jon for tackling the issues. I concur with what has been said so far. Especially what James said, that there are so many places where one possibly/maybe/theoretically could come up with timing attacks. Mitigating the difference in response co

Re: Revisiting Python support for after Django 3.2 LTS

I think I need to go through all proposed options a few more times to understand their differences and implications. But what about a more pragmatic approach: Django supports the currently supported Python versions at any given time. Except for our LTS versions, which would never drop support.

Re: The blacklist / master issue

Hi all, Reviving an old topic. GitHub has by now tooling in place to rename branches and keep open PRs in sync. In fact, if I were to change the `master` branch to `main`, GitHub tells me this: Renaming this branch: * Will update 158 pull requests targeting this branch across 112 repositories.

Re: The blacklist / master issue

verything has been smooth since. We'll need some find/replace for > > links in the main repo, on djangoproject.com <http://djangoproject.com>, > > and I imagine some other places. > > > > On Tue, 23 Feb 2021 at 22:15, Kenneth > <mailto:kennethl...@gma

Re: The blacklist / master issue

eb 25, 2021, at 7:31 PM, Markus Holtermann wrote: > Thanks for the input, Matthias. That's useful to know. I'll make sure > the change is announced. > > Cheers, > > Markus > > On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote: > > Yes, please.

Re: The blacklist / master issue

Hi all, Mariusz renamed the branches this morning and merged the corresponding pull requests. Thank you! Please let us know if you spot problems so they can be fixed. Cheers, Markus On Tue, Mar 2, 2021, at 6:05 PM, Markus Holtermann wrote: > Brief update on this. > > The overall

Re: Proposal to add attribute 'step' to FloatField and DecimalField

Hi Jacob, That sounds like a sensible feature. Do you want to open a ticket and maybe implement it? Cheers Markus On Wed, Mar 17, 2021, at 12:45 AM, Jacob Rief wrote: > If someone wants to use the step attribute as provided by the HTML field > , she/he has to specify that using for instance >

Re: Default change password UX: area for improvements

Hi Federico, this is a good idea. Could you check if there's a ticket about this on https://code.djangoproject.com/ already, and if not, possibly open one. That would be much appreciated. Thank you! Cheers, Markus On Mon, Jun 7, 2021, at 11:12 PM, Federico Capoano wrote: > Hey everyone, > >

Re: The certificate for code.djangoproject.com expired on 7/4/2021.

We had some intermittent connection issues over the last couple of hours: https://status.djangoproject.com/. All should be fine again. Cheers On Sun, Jul 4, 2021, at 4:14 PM, chris.j...@gmail.com wrote: > Maybe someone can file an issue about it to address the same thing > happening in the fut

Re: RSS access to Google groups?

Hi Claude, I think you're receiving everything because you're a moderator everywhere and they get everything they're moderating by default. I'd need to look into this a bit more. But I think there's a way to disable excess notifications. Cheers, Markus On Fri, Aug 13, 2021, at 10:53 PM, Claud

Re: Proposal for a transaction.on_before_commit

Hi Raphael, This is funny. Just last week I looked into exactly the same thing for audit logging as well. Except that I'm writing multiple audit log events and want to batch them at the end of the transaction in a single bulk_create operation instead of a dozen save() calls. I haven't gotten a

Re: Preparing Django code for the Black stable release

There is https://github.com/MarkusH/django-migrations-formatter which I think holds everything that's necessary to make the migration writer create black-formatted output. Cheers, Markus On Wed, Oct 20, 2021, at 11:11 AM, 'Adam Johnson' via Django developers (Contributions to Django itself) w

Re: Preparing Django code for the Black stable release

That's wonderful news. Thanks for the info, Paolo! Cheers, Markus On Sat, Jan 29, 2022, at 10:24 PM, Paolo Melchiorre wrote: > Hi all, > > Black 22.1.0 has just been released > https://github.com/psf/black/releases/tag/22.1.0 > > It seems the time has come to put DEP 0008 into practice and "run

  1   2   >