Hello, I've *at last* had some time to experiment with the idea I had thrown years again, of a system to workaround the recurring breakages introduced by new django releases, breakages which sometimes lead to unreconcilable requirements between django apps.
After a sprint at PyconFR, with a colleague (R. Gomès), and some cleanups and improvements, here it is: https://github.com/pakal/django-compat-patcher (also known as DCP) https://pypi.python.org/pypi/django-compat-patcher The philosophy of the module is that, with extremly agile languages such as python, one doesn't have to choose between a fast-moving project, and a compatibility-friendly project. So, in an approach reminding "aspect oriented programming", DCP separates the Django codebase, which may move forward and be left mostly free of compatibility shims, from retrocompatibility shims ; and changing the "level of compatibility" of a project is just the matter of tweaking some Django settings. Since, as usual, "explicit is better than implicit", logging and code warnings are used to ensure that project users are informed about what compatibility fixers are applied, and how project dependencies are rated deprecation-wise. I've noticed there had been debates and evolutions for the past years, until the switch to a "lax semantic versioning" for Django. Surely it's an effort in the right direction, but I guess I'm not the only one worried by the "lax" adjective ; especially after the long history of breakages occurring for quite cosmetic reasons (eg. the removal of urlpatterns(), which broke most django apps available, whereas dotted-path URLs were rather harmless). That's why I think DCP is still relevant, as it gives back some control over compatibility to end users of Django ; and it should remove part of the apprehension some may have known too, when installing a new Django version. DCP has been successfully used to upgrade wide projects from django 1.7 to django 1.10, with no hassle. But more feedback would be nice, before it can be marked "production ready". The project welcomes patches, especially new backward/forward compatibility fixers one might need. *Apart from that *: I think many people could benefit from more instructions about how to handle (backwards and forwards) compatibility, so here are some ideas I had : *1) Advertising compatibility systems for Django, in the official docs.* That is to say, packages like "django-compat" (which I only discovered lately), dedicated to library developers who need a wide compatibility. And packages like "django-compat-patcher" for project maintainers who have compatibility issues and deadlines (it's not *always* the right moment to fork and patch a bunch of big dependencies). All that would come in addition to the docs now mentioning "how to support 2 LTS versions at a time". These measures might diminish the number of django app using handmade compatibility shims, or completely ignoring previous versions of django. *2) Pushing a compatibility system like DCP into Django itself* What would be the gain ? It would pleasantly reduce the work needed for Django evolutions. At the moment, first compatibility shims must be introduced, and specifically tested in code ; then these compatibility shims must be removed, and their tests with them. With a separate compatibility system, only half the work would be needed : once the code has been modified, the old version is moved to a fixer, and its associated unit-test is moved to the compatibility system test suite. The activation/deactivation of this particular fixer is then only a matter of django settings, not of new code commits. Most importantly, this way, django main tests suites would stop making asserts on the presence or absence of deprecation warnings (which is a way of mixing unrelated aspects of the framework). Django tests suites could thus be leveraged by compatibility systems to ensure that the whole system is well sane and backwards/forward compatible, whatever the series of django shims applied. *Any remarks about DCP concept itself, or about suggestions for doc/core inclusions ?* thanks, regards, Pascal -- 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/37750f9b-d5e4-4216-a510-546502c084c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
