Hi Dmitry, thanks for the alternative way, however it seems more a *complement *than a replacement of DCP.
Indeed, your "rewriting" approach updates a codebase to support the latest django API, but it raises a number of issues : - how could it be applied to django reusable apps, installed via pip ? Does it mean a package hook should be used to automatically transform code on "pip install" for django-related modules, as setuptools allows it for the 2to3 case ? Or a special import hook for django ? - it doesn't ensure backwards compatibility of the updated module, so unless every django-app maintainers use that system to stick to the latest django version, conflicts would remain when handling big projects. - imo it can only handle trivial changes (renames mostly) ; when features disappear, or are replaced by much different approaches, unless this rewritter itself injects big shims, it wouldn't work. For example, the SortedDict, in which keys could be inserted at arbitrary positions, has been replaced by stdlib OrderedDict which is "readonly", so the code around needs to be rethought accordingly. That being said, I guess everyone would love it, if they could upgrade THEIR codebase semi-automatically, instead of doing mass regex search/replaces. There are plenty of AST modifiers for python ( https://github.com/berkerpeksag/astor, or others, pytest does some nifty ast hacking too...), else a regex based django-command would already be nice too. regards, Pascal Chambon 2017-01-22 22:38 GMT+01:00 Dmitry Gladkov <dmitry.glad...@gmail.com>: > Hi, > > Making Django upgrades less painful is a great goal, but I believe the > patching Django and restoring removed functionality is not the right > solution. JavaScript world has the same problem with far more frequent > major compatibility breakages and they solve it with automatic codebase > upgrade tools like jscodeshift [1]. This approach uses AST transformation > similar to what 2to3 does, but with configurable transformation rules. > There's also another project written in Python [2] that implements simpler > and more general, but less reliable regex-based approach. > > I believe adding codebase upgrade rules for each major Django release and > giving users ability to apply them by running something like ./manage.py > upgrade_from 1.7 after Django upgrade will greatly simplify upgrading of > large Django projects. > > [1] https://github.com/facebook/jscodeshift > [2] https://github.com/facebook/codemod > > -- > Best wishes, > Dmitry Gladkov > > On 22 January 2017 at 20:53, Pascal Chambon <chambon.pas...@gmail.com> > wrote: > >> Hi, >> >> @James Pc - thanks for the support, if you happen to miss some fixers in >> DCP and don't have the opportunity to contribute them, please open an issue >> so that I have a look >> >> @Tim Graham & James James Bennett - from what I sum up, the new policy >> simply extends the delay between breaking changes, and so the overall life >> expectancy of django reusable apps, but other limitations remain as is. >> I've detailed the misc benefits that a compatibility layer would bring, I >> just hope not too many people needing big compatibility will fail to learn >> about django-compat or DCP, and complicate their life with handmade shims >> or useless forks. >> >> regards, >> Pascal >> >> 2017-01-16 10:48 GMT+01:00 James Bennett <ubernost...@gmail.com>: >> >>> On Sun, Jan 15, 2017 at 1:09 PM, Pkl <chambon.pas...@gmail.com> wrote: >>> >>>> My bad, if people are guaranteed 2 x 24-month cycles before a feature >>>> gets removed, it's already much better. However, the same pattern as >>>> previously appears in docs : "each feature release will continue to have a >>>> few documented backwards incompatibilities where a deprecation path isn’t >>>> possible or not worth the cost.". I might be paranoid, but I foresee lots >>>> of dependency breakages in the future, if incompatibilities continue to be >>>> introduced at developer's will.... History proved even seemingly harmless >>>> django modifications (ex. import aliases removed) broke external code, >>>> sometimes forcing "commit reverts" in django code. >>>> >>> >>> Just to clarify, the future plan -- beginning with Django 2.0, the next >>> release after 1.11, which is about to feature-freeze -- is: >>> >>> 1. Releases go in a cycle of X.0, X.1, X.2, (X+1).0. So, for example, >>> 2.0, then 2.1, then 2.2, then 3.0. >>> 2. Each X.2 is an LTS. >>> 3. Code which runs with no deprecation warnings on an LTS will also run >>> (though may raise deprecation warnings) on the next LTS. >>> 4. Thus, any time you run on an LTS with no deprecation warnings, you >>> know you're safe to upgrade to the next LTS. And once you clear any new >>> deprecation warnings on the new LTS, you know you're clear to upgrade to >>> the one after that. >>> >>> Regarding backwards-incompatible changes in general: they do happen, but >>> they also follow the guidelines in the API stability document. When they >>> occur, it's because there's a security issue or larger bug being solved. >>> Additionally, many of the seemingly-large list of such changes each release >>> are, if you dig into them, changes to private/internal or at least >>> undocumented APIs not covered by the stability policy, but we've learned >>> people still rely on those APIs and so we document changes to them even if >>> we don't guarantee stability in them. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>> pic/django-developers/dKeLB-qR7lY/unsubscribe. >>> To unsubscribe from this group and all its topics, 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/ms >>> gid/django-developers/CAL13Cg8_0BRpu1b_zz2Dx_YXcLaXGXw8Qw0jf >>> A_uDhaxt%3DD_%3Dw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CAL13Cg8_0BRpu1b_zz2Dx_YXcLaXGXw8Qw0jfA_uDhaxt%3DD_%3Dw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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/ms >> gid/django-developers/CA%2BXNUS35Au2um1an3bV-P8q%3DivfOM067r >> 3Qay4jntd%2BCHADkPg%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CA%2BXNUS35Au2um1an3bV-P8q%3DivfOM067r3Qay4jntd%2BCHADkPg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/django-developers/dKeLB-qR7lY/unsubscribe. > To unsubscribe from this group and all its topics, 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/CA%2BkbqrW0F8YZSn8v5wkApAx9Z7a7Q2 > 0drM7z%3Dxn26qR4DsU7ng%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CA%2BkbqrW0F8YZSn8v5wkApAx9Z7a7Q20drM7z%3Dxn26qR4DsU7ng%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CA%2BXNUS0qeOVqwe99dKwk1rsdP7xBD0WmQN8kAurZ91DeNuyO-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
