Skip to content

Fixed writer_name deprecation warning in docutils 0.22+. #19684

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 30, 2025

Conversation

felixxm
Copy link
Member

@felixxm felixxm commented Jul 29, 2025

@github-actions github-actions bot added the no ticket Based on PR title, no linked Trac ticket label Jul 29, 2025
Copy link
Contributor

@nessita nessita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Perfect timing 🎯

From the release notes:

Remove the "reader_name", "parser_name", and "writer_name" arguments of core.Publisher.init() and the core.publish_*() convenience functions as well as the "parser_name" argument of Reader.init() in Docutils 2.0. Since Docutils 0.22, you may use "reader", "parser", and "writer" arguments for component names as well as instances.

@nessita nessita merged commit 65ab92f into django:main Jul 30, 2025
35 of 36 checks passed
@nessita
Copy link
Contributor

nessita commented Jul 31, 2025

I initially merged this and backported it to 5.2.x to avoid test failures (or any issues) with docutils 0.22+, since we do not currently pin the dependency beyond requiring 0.19 or higher.

However, after a closer look, this is actually a backward incompatible change for 5.2.x — docutils < 0.22 does not support this usage and breaks as a result.

To address this, I’m proposing PR #19690, which ensures the docutils.core.publish_parts call works across versions 0.19 through 0.22+ without raising errors.

I think we should consider applying this to main (possibly targeting main first and then backporting it), which would allow us to maintain compatibility without needing to bump the minimum docutils version to 0.22+ for Django 6.0 (i.e. we would not need to land PR #19686 for now, IMHO).

@felixxm @sarahboyce do you have a preference?

@nessita
Copy link
Contributor

nessita commented Jul 31, 2025

I created ticket-36535 to keep track of this issue.

@felixxm
Copy link
Member Author

felixxm commented Jul 31, 2025

I created ticket-36535 to keep track of this issue.

I missed this, sorry. I can fix it if you want.

@felixxm
Copy link
Member Author

felixxm commented Jul 31, 2025

@felixxm @sarahboyce do you have a preference?

Personally, I'd not bother about the main branch. Theoretically, docutils < 0.22 doesn't support Python 3.12+ 🤷

@felixxm felixxm deleted the docutils branch July 31, 2025 17:54
@nessita
Copy link
Contributor

nessita commented Jul 31, 2025

I created ticket-36535 to keep track of this issue.

I missed this, sorry. I can fix it if you want.

No worries! I think I have a PR with a fix: #19690

The question is whether we want to target main instead (and then I backport). It seems like a safe approach and I have slight preference to got this route.

@nessita
Copy link
Contributor

nessita commented Jul 31, 2025

@felixxm @sarahboyce do you have a preference?

Personally, I'd bother about the main branch. Theoretically, docutils < 0.22 doesn't support Python 3.12+ 🤷

Ok, this is a fair point and we may avoid future headaches by bumping minimum supported version to 0.22 on 6.0 and above. Let's keep the other PR targeting 5.2.x only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no ticket Based on PR title, no linked Trac ticket
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants