ฉันคิดว่าฉันจะเพิ่มกลยุทธ์ที่สนับสนุนโดยคำตอบของ Wim - รับรุ่นที่เหมาะสมของ Django ที่ทำงานทั้ง 2.7 และ 3.x ก่อน - และร่างกลยุทธ์บางอย่างที่เหมาะกับฉัน
Python 2.7 เป็นพ็อดการหลบหนีของคุณจนกว่าคุณจะดึงทริกเกอร์บน 3.x
- การทดสอบของคุณควรทำงานทั้งสองอย่าง
- อย่าใช้คุณสมบัติเฉพาะ 3.x เช่น f-strings
- Python 3.x ตัวแรกจากนั้นต่อมา Django 2.x ซึ่งไม่ได้ทำงานบน 2.7
- เริ่มเร็วอย่าวิเคราะห์มากเกินไป แต่หลีกเลี่ยงวิธีบิ๊กแบง
- ไฟล์โดยไฟล์ที่แรก
- เริ่มต้นด้วยรหัสระดับต่ำสุดเช่นไลบรารียูทิลิตี้ที่คุณมีห้องชุดทดสอบ
- ถ้าเป็นไปได้พยายามค่อยๆรวมการเปลี่ยนแปลงของคุณเข้ากับสาขาการผลิต 2.7 และทำให้รหัสการย้ายพอร์ต 3.x เป็นปัจจุบันด้วยการเปลี่ยนแปลงที่เกิดขึ้น
เวอร์ชันไหนของ Django ที่จะเริ่มด้วย
เกณฑ์ของฉันในที่นี้คือการโยกย้าย Django สามารถมีส่วนร่วมได้อย่างเป็นธรรม (และต้องการการคิดมากกว่า 2 => 3 งาน) ดังนั้นฉันจะย้ายไปที่ล่าสุดและที่ยิ่งใหญ่ที่สุด 1.11 วิธีที่คุณให้คุณค่ากับผู้ใช้ 2.7 ของคุณอยู่แล้ว อาจมีความเข้ากันได้ pre-2.x ที่ดีในวันที่ 1.11 และคุณจะได้รับคำเตือนที่ 2.x
Python 3.x รุ่นรองรุ่นใดที่จะเริ่มต้นด้วย
ที่ดีที่สุดที่จะต้องพิจารณาทุกมุมเช่นความพร้อมใช้งานของ libs บุคคลที่สามการสนับสนุนจากชุด CI / devops ของคุณและความพร้อมใช้งานบนอิมเมจเซิร์ฟเวอร์ OS ที่คุณเลือก คุณสามารถติดตั้ง 3.8 และลองติดตั้ง pip ของ requirements.txt ของคุณด้วยตัวเองตัวอย่างเช่น
Leverage คอมไพล์ (หรืออะไรก็ตามที่คุณใช้ SCM) และvirtualenv
- แยก
requirement.txtไฟล์ แต่ ...
- ถ้าคุณมีไฟล์ตาม repo คอมไพล์คุณสามารถชี้แต่ละ venv ที่codeline เดียวกัน
pip install -e <your directory>กับ นั่นหมายความว่าใน 2 เทอร์มินัลต่าง ๆ คุณสามารถรัน 2.7 และ 3.x เทียบกับ unittest เดียวกัน
- คุณสามารถเรียกใช้เซิร์ฟเวอร์ Django 2.7 และ 3.x เคียงข้างกันบนพอร์ตที่แตกต่างกันและชี้ว่า Firefox และ Chrome อยู่ด้วย
- กระทำอย่างสม่ำเสมอ ( อย่างน้อยก็ในสาขาการย้าย) และเรียนรู้เกี่ยวกับgis bisect
ใช้ประโยชน์จาก2to3
ใช่มันจะทำลายรหัส 2.7 และ Django ถ้าคุณปล่อยให้มัน ดังนั้น...
นี่คือคำสั่งที่ควบคุมปริมาณของฉันดูเหมือน:
2to3 $tgt -w -f except -f raise -f next -f funcattrs -f print
- เรียกใช้ไฟล์ต่อไฟล์จนกว่าคุณจะมั่นใจจริงๆ
ใช้sedหรือawkแทนการแก้ไขของคุณสำหรับการแปลงจำนวนมาก
ข้อดีคือเมื่อคุณตระหนักถึงข้อกังวลเฉพาะของแอพมากขึ้นคุณสามารถสร้างชุดการเปลี่ยนแปลงที่สามารถเรียกใช้บนไฟล์ 1 ไฟล์หรือไฟล์จำนวนมากและทำงานส่วนใหญ่โดยไม่ทำลาย 2.7 หรือ Django สมัครตำแหน่งนี้หลังจากที่คุณเหมาะสม-ผ่อนคันเร่ง2to3ผ่าน สิ่งนี้ทำให้คุณมีการสะสางเหลืออยู่ในเครื่องมือแก้ไขและทำการทดสอบให้ผ่าน
(เป็นทางเลือก) เริ่มรันสีดำบนโค้ด 2.7
black ซึ่งเป็นตัวจัดรูปแบบโค้ดใช้ Python 3 AST เพื่อเรียกใช้การวิเคราะห์ ไม่พยายามเรียกใช้รหัส แต่จะตั้งค่าสถานะข้อผิดพลาดทางไวยากรณ์ที่ป้องกันไม่ให้เข้าสู่ขั้นตอน AST คุณจะต้องทำงาน pip ติดตั้งเวทย์มนตร์ระดับโลกเพื่อไปที่นั่นและคุณจะต้องซื้อเพื่อประโยชน์ของคนผิวดำ
คนอื่นทำได้ - เรียนรู้จากพวกเขา
การฟัง# 155 ขั้นตอนปฏิบัติสำหรับการย้ายไปยัง Python 3ควรให้แนวคิดบางอย่างเกี่ยวกับการทำงาน ดูลิงค์แสดงมัน พวกเขาชอบพูดถึงการย้าย Instagram (?) ซึ่งเกี่ยวข้องกับการปรับการรัน 2.7 รหัสเป็น 3.x ซินแท็คซ์บน codebase ทั่วไปและในสาขา git เดียวกันจนถึงวันดึง
ดูคู่มือการย้ายพอร์ตแบบอนุรักษ์นิยม Python 3
และInstagram ทำให้การย้ายราบรื่นไปยัง Python 3 - The New Stack
ข้อสรุป
เวลาของคุณไปยัง Django 1.11 EOL (เมษายน 2563) ค่อนข้างสั้นดังนั้นหากคุณมีทรัพยากร 2+ ตัวที่จะขว้างมันฉันจะลองทำสิ่งต่อไปนี้ควบคู่กัน:
DEV # 1: เริ่มจาก Django 1.11 bump (ทฤษฎีที่ว่า 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 เริ่มต้นของคุณจะช้า แต่เครื่องมือและคำแนะนำนั้นดีพอที่คุณจะรับความเร็วได้อย่างรวดเร็วดังนั้นอย่าคิดมากก่อนที่จะเริ่มรวบรวมประสบการณ์ ด้าน Django ขึ้นอยู่กับการเปิดเผยของคุณต่อการเปลี่ยนแปลงในกรอบซึ่งเป็นสาเหตุที่ฉันคิดว่ามันเป็นการเริ่มต้นที่ดีที่สุด
ป.ล. (ความเห็นแย้ง / ความเห็นส่วนตัว) ฉันไม่ได้ใช้ห้องสมุดบริดจ์แบบ 2 ต่อ 3 จาก6หรืออื่น ๆ อีกมาก
มันไม่ได้เพราะผมไม่ไว้วางใจได้ - มันยอดเยี่ยมสำหรับ libs บุคคลที่ 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)แต่ฉันรู้ล่วงหน้าว่ามีอะไรต้องกังวลน้อยมาก