I've started working on a tool provides a set of codemodders <https://libcst.readthedocs.io/en/latest/codemods_tutorial.html> for Django:
https://github.com/browniebroke/django-codemod It's based on Instagram's libCST <https://libcst.readthedocs.io/en/latest/index.html> (work with Concrete Syntax Tree). This is very much a work in progress, but I think it could help with these kind of deprecations that require changing a lot of files. I'm not really satisfied by the API of the CLI, I would prefer to get something like pyupgrade, where you specify your min & max Django version, but I guess it's better than nothing. It's very much a work in progress and feedback is welcome! On Saturday, 9 May 2020 17:13:51 UTC+1, Adam Johnson wrote: > > Automated upgrade tooling would be great. Developers end up building their > own anyway. > > One more tool we could copy is pyupgrade ( > https://pypi.org/project/pyupgrade/ ). It's based upon an extension to > 'tokenize' by the author (Anthony Sottile) that allows roundtripping (which > I guess would be useful being merged to the stdlib). But it also looks > possibly painful to work with. > > I've tried Bowler and it has a nice interface, allowing git-add-patch > presentation through its idiff() command. But it doesn't have many examples > in its documentation, which made me give up. It's also based on lib2to3, > through a separated copy called fissix. > > codemod's README lists Python 2 support only :( > > regexes for find/replace, maybe with a sed command, would be the lowest > common denominator. Combined with "git add --patch", then "git checkout ." > that's basically what codemod does (afaiu). > > On Sat, 9 May 2020 at 13:32, Aymeric Augustin < > aymeric...@polytechnique.org <javascript:>> wrote: > >> Hello, >> >> When proposing deprecations that require numerous but simple code >> changes, providing an automated upgrade path could reduce frustrations >> about "useless churn". >> >> Unfortunately, I don't know a great way to do that on Python code. Here >> are the options I'm aware of: >> >> - Writing 2to3 fixers is painful, in my experience >> <https://github.com/django/django/commit/79d62a71751140315227891bbe175630f9d3edc3>. >> >> Also, I don't think that 2to3 will survive the deprecation of lib2to3; >> removal is scheduled for Python 3.12. >> - Bowler <https://pybowler.io/> seems designed to make it less painful, >> but is also written on top of lib2to3, so not a long term solution. >> - codemod <https://github.com/facebook/codemod> gives up fully automated >> refactoring (which is at odds with Python's dynamic nature) and attempts >> "computer-aided refactoring". >> - Most likely IDEs like PyCharm can rename an import throughout a project. >> >> If I had to do something in this area, I'd try codemod, probably. >> >> Of course, it will still be boring to perform the same change across N >> projects for no direct project-level upside, but at least it may require >> less time and less focus. >> >> This is relevant for the thread about renaming request.GET/POST/etc. If >> we proceed with that change, we're bound to have the exact same discussion >> about removing the original names. >> >> Best regards, >> >> -- >> Aymeric. >> >> >> >> On 5 May 2020, at 17:41, Collin Anderson <cmawe...@gmail.com >> <javascript:>> wrote: >> >> Hi All, >> >> Are we _sure_ we want to completely get rid of url()? >> >> Yesterday, url() was given a RemovedInDjango40Warning [PR]. The removal >> was approved as part of the new path() syntax back in 2017 [DEP 0201]. >> >> Is this really worth it? It's only a *few lines of code* to keep >> backward compatibility, and it seems to me it would take *almost no work >> to maintain* that compatibility shim compared to the countless >> programmer hours needed to upgrade their code, including many unpaid >> programmers working on open source projects. I'll personally need to do a >> find/replace for url() to re_path() across my ~20 projects, and update all >> of the imports. Isn't this *useless code churn*? >> >> Yes, there's an advantage to having one and only one way to do it, so I >> agree we should encourage people to use re_path() instead of url(), but >> shouldn't we also make it *as easy as possible to upgrade django*? Is >> getting rid of url() really worth the cost? >> >> Yes, the removal is still ~3+ years away, but that's a question of _when_ >> not _if_. >> >> If we want, we _could_ deprecate url() without giving it an actual >> removal date [Compatibility Discussion] and leave the compatibility shim >> around longer, if not indefinitely. >> >> Thanks, >> Collin >> >> >> [PR] https://github.com/django/django/pull/12855 >> >> [DEP 0201] >> https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst >> >> [Compatibility Discussion] >> https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion >> >> -- >> 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-d...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- >> 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-d...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/236BB3BC-B228-4676-8955-4E302A38197F%40polytechnique.org >> >> <https://groups.google.com/d/msgid/django-developers/236BB3BC-B228-4676-8955-4E302A38197F%40polytechnique.org?utm_medium=email&utm_source=footer> >> . >> > > > -- > Adam > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b1a25373-9102-4b1c-a0ad-78eedf335aa5%40googlegroups.com.
