Skip to content
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

Support more compatibility import rewrites #293

Closed
UnknownPlatypus opened this issue Nov 12, 2022 · 2 comments · Fixed by #368
Closed

Support more compatibility import rewrites #293

UnknownPlatypus opened this issue Nov 12, 2022 · 2 comments · Fixed by #368

Comments

@UnknownPlatypus
Copy link
Contributor

UnknownPlatypus commented Nov 12, 2022

Description

I noticed while browsing django codebase for warnings.warn that some (rather old) compatibility imports were not supported by django-upgrade.

Do you think it could be a valuable addition ?

I was thinking of using a similar pattern to anthony's compatibility import plugin by keeping a mapping of django-version -> import (similar to the current REWRITES mappings) while still relying on the django-upgrade update_import_modules for the actual fixing.

This could maybe lead to a small performance improvement too by grouping the existing fixer that are mostly checking the same things. As always, I'm happy to send a PR!


Here are the compatibility imports that I think are not currently covered.

Imports

--target-version 2.0

  • django.utils.decorators.ContextDecorator -> contextlib.ContextDecorator: Undocumented - source

--target-version 1.11

  • django.test.runner.setup_databases() -> django.test.utils.setup_databases() : release note - source - RemovedInDjango21

--target-version 1.10

  • django.contrib.staticfiles.templatetags.staticfiles.static() -> django.templatetags.static.static(): release note - source 1.10 - RemovedInDjango30
  • django.core.urlresolvers.* -> django.urls.*: release note - source - RemovedInDjango20

--target-version 1.9

  • django.db.backends.postgresql_psycopg2.* -> django.db.backends.postgresql.*: release note - source - RemovedInDjango30.
  • django.forms.extras.SelectDateWidget -> django.forms.widgets.SelectDateWidget: release note - source - RemovedInDjango20

--target-version 1.8

  • django.core.context_processors.* -> django.template.context_processors.*: release note - source - RemovedInDjango110
  • django.db.models.sql.aggregates -> django.db.models.aggregates: release note - source - RemovedInDjango110

--target-version 1.6

  • django.template.base.Context -> django.template.context.Context: Same for BaseContext, ContextPopException and RequestContext: release note - source - RemovedInDjango31

--target-version 1.1

  • django.contrib.admin.ACTION_CHECKBOX_NAME -> django.contrib.admin.helpers.ACTION_CHECKBOX_NAME : release note - source - RemovedInDjango31
@adamchainz
Copy link
Owner

Whilst most of the imports you’ve found are from pretty old versions, I think it could be valuable to group the pure import move fixers in one. I think it would be best if you could make a first PR that groups them, before we add any new ones.

Also I wouldn’t want to add any older versions than we already support (1.7), just for a few import changes.

@UnknownPlatypus
Copy link
Contributor Author

I think it would be best if you could make a first PR that groups them, before we add any new ones.

Makes sense, will start with the grouping then.

Also I wouldn’t want to add any older versions than we already support (1.7), just for a few import changes.

yeah, most of them could be grouped into existing target-version maybe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants