Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

[Dmitry Gladkov]

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 
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 :
>
>> On Sun, Jan 15, 2017 at 1:09 PM, Pkl  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
>> 
>> .
>>
>> 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.

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

[Pascal Chambon]

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 :

> On Sun, Jan 15, 2017 at 1:09 PM, Pkl  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/
> 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/CAL13Cg8_0BRpu1b_zz2Dx_
> YXcLaXGXw8Qw0jfA_uDhaxt%3DD_%3Dw%40mail.gmail.com
> 
> .
>
> 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%2BXNUS35Au2um1an3bV-P8q%3DivfOM067r3Qay4jntd%2BCHADkPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing and renaming Django's Python 2 related helpers

[Adam Johnson]

I don't think a deprecation warning is necessary for removing the vendored
libraries. The main things that are used are django.utils.six and
django.utils.lru_cache which are both easily available separately on PyPI
for Python 2/3 compatibility anyway. The warning would probably just make
libraries move to the PyPI versions whilst they still support Python 2.

On 21 January 2017 at 22:51, Tim Graham  wrote:

> Considering the things mentioned so far are zero maintenance effort for
> Django (the only downside I see is 30kB for the bundled six), I'd rather
> keep the shims until 2025 rather than spend any time on a more complex
> solution. These removals are all very straight forward find/replaces, so I
> don't think warnings provide much benefit in identifying them. Even if you
> want to check your third-party apps, you can grep your virtual environment
> directory. My 2 cents, but I'm an enthusiast and less interested users may
> find warnings useful, I suppose.
>
>
> On Saturday, January 21, 2017 at 4:41:59 PM UTC-5, Shai Berger wrote:
>>
>> On Saturday 21 January 2017 22:55:51 Tim Graham wrote:
>> >
>> > I'm advocating to remove the undocumented things in Django 3.0
>> (released
>> > Dec. 2019) or later without a deprecation. By that time, I hope
>> third-party
>> > apps won't support Python 2 either and so part of adding Django 3.0
>> > compatibility will include formally dropping support for Python 2 (if
>> not
>> > done already) and removing usage of this stuff (a fairly easy
>> find/replace,
>> > hopefully).
>> >
>> > Others have advocated to deprecate all these things, but I don't see
>> much
>> > advantage. If I were maintaining an app, I'd rather be able to use
>> import
>> > shims without warnings until Python 2 is gone. What's your preference?
>> >
>>
>> I think that in order to help 3rd-party apps manage the move towards
>> dropping
>> Python 2 support, we should decouple the deprecation of Py2 shims from
>> other
>> Django deprecations. So, I'm thinking we should have a new warning class,
>> something like "Python2DeprecationWarning"; this would be easy enough to
>> silence for people who want to keep using them -- we could even provide a
>> context-manager based on warnings.catch_warnings() that would
>> specifically
>> silence this warning, so 3rd-parties could silence it on their own uses
>> easily.
>>
>> That's eating the warnings cake while keeping it whole, as far as I can
>> see.
>>
>> Shai.
>>
> --
> 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/b941c792-57c7-4913-82f3-
> 68a2ce357390%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 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/CAMyDDM3rhuypW4b57QLdcM3CHfmeWZ%2BrLP%2BeiwPZM0PY6V0esA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.