Я думав, що я додам трохи до стратегії, яку підтримує відповідь Віма, - спочатку знайдіть відповідну версію Джанго, яка працює як на 2.7, так і на 3.x - і окреслю деякі тактики, які працювали на мене.
Python 2.7 - це ваш рятувальний майданчик, поки ви не натиснете курок на 3.x
- ваші тести повинні працювати на обох
- не використовуйте жодних особливих функцій 3.x, як-от f-string
- спочатку Python 3.x, потім лише пізніше Django 2.x, який не працює на 2.7
- почніть рано, не надмірно аналізуйте, але уникайте підходу великого удару
- файл спочатку за файлом.
- почніть з найнижчого рівня коду, як бібліотеки утиліт, для яких у вас є тестові набори.
- якщо це можливо, спробуйте поступово об'єднати свої зміни до 2,7 виробничих галузей і забезпечити оновлення коду перенесення 3.x із змінами prod.
З якої другої версії Джанго почати?
Мої критерії тут полягають у тому, що міграції Джанго можуть бути досить задіяними (і насправді вимагають більше мислення, ніж 2 => 3 роботи). Тож я перейшов би до останнього та найбільшого 1.11 таким чином, ви вже надаєте деяку цінність своїм 2,7 користувачам. Напевно, існує достатня кількість сумісностей, що працюють до 2.x, на 1.11, і ви отримуватимете її попередження про скорочення 2.x.
З якої другої версії Python 3.x почати?
Найкраще врахувати всі кути, такі як наявність ваших сторонніх ліфтів, підтримка вашого пакета CI / devops та доступність обраних обраних вами серверів ОС. Ви завжди можете встановити 3.8 і спробувати встановити файл pip своїх вимог.txt, наприклад, сам.
Використовуйте git (або будь-яку scm, яку ви використовуєте) та virtualenv .
- окремі
requirement.txtфайли, але ...
- якщо у вас є файлова програма git repo, ви можете вказати кожен venv на одну і ту ж кодову лінію з a
pip install -e <your directory>. це означає, що в двох різних терміналах ви можете запустити 2.7 і 3.x проти одних і тих же одиничних тестів.
- ви навіть можете запускати 2,7 та 3x сервери Django поруч на різних портах і вказувати на них Firefox та Chrome.
- вчиняйте часто (принаймні на переносній гілці) та дізнайтеся про git bisect .
використовувати 2to3
Так, він зламає 2,7 код і Django, якщо ви дозволите. Тому...
запустіть його в режимі попереднього перегляду або проти одного файлу. дивіться, що це ламає, а також дивіться, що він зробив правильно.
пригнічуйте його лише до певних конверсій, які не порушують 2.7 або Django. print x=> print (x)і except(Exception) as eє двома моніторами.
Ось так виглядала моя затискаюча команда:
2to3 $tgt -w -f except -f raise -f next -f funcattrs -f print
- запускайте його по файлу, поки ви не впевнені в собі.
використовуйте sed або awk, а не редактор для масових конверсій.
Перевага полягає в тому, що, коли ви станете більш обізнаними зі специфікою своїх додатків, ви можете створити набір змін, які можна виконати на 1 файлі або на багатьох файлах і виконати більшу частину роботи, не порушуючи 2.7 або Django. Застосуйте це після відповідного пропуску 2to3 . Це залишає вас із залишками очищення у вашому редакторі та проходить тести.
(необов’язково) почніть працювати чорним кольором на 2,7 коді.
чорний, який є форматором коду, використовує Python 3 ASTs для запуску свого аналізу. Він не намагається запустити код, але позначить помилки синтаксису, які заважають йому потрапити на етап AST. Вам доведеться попрацювати з деякими технологіями встановити глобальну магію, щоб потрапити туди, і вам доведеться купувати корисність чорного.
Інші люди це зробили - вчіться у них.
Прослуховування №155 Практичні кроки для переходу на Python 3 повинні дати вам декілька ідей роботи. Подивіться на посилання на шоу. Вони люблять спілкуватися з ходом Instagram (?), Який передбачав поступове налаштування запущеного 2,7 коду до синтаксису 3.x на загальній базі коду та в тій же гітці git, поки не відбудеться день запуску.
Дивіться також Посібник з перенесення консервативного Python 3
і Instagram робить плавний перехід до Python 3 - The New Stack
Висновок
Ваш час на Django 1,11 EOL (квітень 2020 р.) Досить короткий, тому якщо у вас є 2+ розроблених ресурсів, я б розглядав паралельно наступні дії:
DEV №1: почати з удару Django 1,11 (теорія полягає в тому, що Django 1.11, мабуть, найкраще позиціонується як точка стрибка до Django 2.x), використовуючи 2.7.
DEV №2: розпочніть роботу з Python 3.6 / 3.7 вашого коду утиліти, що не належить Django. Оскільки код на даний момент сумісний із 2.7, об’єднайте його у №1 під час переходу.
Подивіться, як обидві завдання діють, оцініть ризик проекту, пов'язаний з Django, і як виглядає біль Python 3 Ви вже пропускаєте Python 2.7 EOL, але застарілий веб-фреймворд, мабуть, небезпечніший, ніж застарілий Python 2.7, принаймні на кілька місяців. Тому я б не чекав занадто довго, щоб почати мігрувати з Django 1.9, і ваша робота при цьому не буде марною. Як побачите прогрес, ви почнете бачити ризики проекту краще.
Ваш початковий прогрес у програмі 2to3 буде повільним, але інструментальне та керівництво досить добре, що ви швидко наберете швидкість, тому не переосмислюйте його, перш ніж починати збирати досвід. Сторона Джанго залежить від вашого впливу на порушення змін у рамках, тому я вважаю, що найкраще починати рано.
PS (суперечлива / особиста думка) Я не користувався шістьма або іншими консервованими мостовими бібліотеками 2 до 3.
Це не тому, що я їй не довіряю - це блискуче для сторонніх ліб, - а саме, що я не хотів додавати складну постійну залежність (і мені було лінь читати її документ). Я давно писав 2,7-код у сумісному синтаксисі 3.x, тому я не відчував потреби в їх використанні. Ваш пробіг може змінюватися і не рухатися на цьому шляху, якщо це здається великою роботою .
Натомість я створив py223.py (57 LOC включно з коментарями) з таким типом вмісту, більшість з яких стосується методів вирішення проблем з анулюваннями та змін назв у стандартній бібліотеці.
try:
basestring_ = basestring
except (NameError,) as e:
basestring_ = str
try:
cmp_ = cmp
except (NameError,) as e:
# from http://portingguide.readthedocs.io/en/latest/comparisons.html
def cmp_(x, y):
"""
Replacement for built-in function cmp that was removed in Python 3
"""
return (x > y) - (x < y)
Потім імпортуйте з цього py223, щоб обійти ці конкретні проблеми. В подальшому я буду просто канаву імпортувати і перемістити ті дивно , isinstance(x, basestr_)щоб , isinstance(x, str)але я знаю заздалегідь , є трохи , щоб турбуватися про.