Phiên bản Python (2.4, 2.5, 2.6, 3.0) nào bạn chuẩn hóa cho các nỗ lực phát triển sản xuất (và tại sao)?

Question

Trong nhóm của chúng tôi, chúng tôi chủ yếu làm công cụ tìm kiếm kiến ​​trúc và tích hợp nội dung công việc và hầu hết các cơ sở mã là trong Python. Tất cả các công cụ xây dựng và phụ thuộc mô-đun Python của chúng tôi đều nằm trong kiểm soát nguồn để chúng có thể được kiểm tra và môi trường được nạp để sử dụng bất kể os/platform, kinda tương tự như cách sử dụng virtualenv.

Trong nhiều năm, chúng tôi đã duy trì cơ sở mã tương thích với Python 2.3 vì một trong các sản phẩm thương mại mà chúng tôi sử dụng tùy thuộc vào Python 2.3. Trong những năm qua điều này đã gây ra nhiều vấn đề hơn khi các công cụ và thư viện mới hơn cần các phiên bản Python mới hơn kể từ khi 2.3 ra mắt vào năm 2004.

Gần đây chúng tôi đã tách môi trường xây dựng của mình khỏi các phụ thuộc vào môi trường của sản phẩm thương mại và có thể sử dụng bất kỳ phiên bản nào của Python (hoặc Java) mà chúng tôi muốn. Nó được khoảng một tháng hoặc lâu hơn kể từ khi chúng tôi chuẩn hóa trên Python 2.6 là phiên bản mới nhất của Python tương thích ngược với các phiên bản trước.

Python 3.0 không phải là một tùy chọn (bây giờ) vì chúng tôi phải di chuyển quá nhiều cơ sở mã của chúng tôi để làm cho công cụ tích hợp và xây dựng của chúng tôi hoạt động bình thường trở lại.

Chúng tôi thích nhiều tính năng mới của Python 2.6, đặc biệt là các mô-đun được cải tiến và những thứ như trang trí lớp, nhưng nhiều mô-đun chúng tôi phụ thuộc vào nguyên nhân trình thông dịch Python 2.6 để kích hoạt nhiều cảnh báo khấu hao khác nhau. Một công cụ khác mà chúng tôi quan tâm để quản lý các nút đám mây EC2, Supervisor thậm chí không hoạt động chính xác với Python 2.6.

Bây giờ tôi tự hỏi liệu chúng ta có nên chuẩn hóa trên Python 2.5 ngay bây giờ thay vì sử dụng Python 2.6 trong phát triển các công cụ môi trường sản xuất hay không. Hầu hết các công cụ chúng tôi muốn/cần có vẻ hoạt động chính xác với Python 2.5. Chúng tôi đang cố gắng sắp xếp điều này ngay bây giờ trước khi có nhiều phụ thuộc vào các tính năng hoặc mô-đun Python 2.6.

Rất cám ơn!

-Michael

Answer 1

Tôi sẽ không từ bỏ 2.6 chỉ vì cảnh báo không dùng nữa; những thứ đó sẽ biến mất theo thời gian. (Bạn có thể sử dụng tùy chọn -W ignore cho trình thông dịch Python để ngăn chúng không được in ra ít nhất) Nhưng nếu các mô-đun bạn cần sử dụng thực sự không hoạt động với Python 2.6, đó là lý do chính đáng để ở lại với 2.5. Python 2.5 hiện đang được sử dụng rộng rãi và có thể sẽ tồn tại trong một thời gian dài (xem xét 2.3 đã kéo dài bao lâu!), Vì vậy ngay cả khi bạn đi với 2.5, bạn sẽ không bị buộc nâng cấp trong một thời gian.

Tôi sử dụng Python 2.5 cho tất cả công việc phát triển của mình, nhưng chỉ vì nó là phiên bản có sẵn trong kho lưu trữ gói của Gentoo (Linux). Khi người bảo trì Gentoo khai báo Python 2.6 "ổn định" *, tôi sẽ chuyển sang điều đó. Tất nhiên, lý do này không nhất thiết phải áp dụng cho bạn.

* Python 2.6 thực sự ổn định, lý do nó không được khai báo trong Gentoo là Gentoo dựa vào các chương trình khác mà bản thân phụ thuộc vào Python và chưa được nâng cấp để làm việc với 2.6. Một lần nữa, lý do này có lẽ không áp dụng cho bạn.

Answer 2

Đối với tôi, điều quan trọng nhất để gắn bó với python 2.5+ là vì nó chính thức hỗ trợ ctypes, thay đổi nhiều hệ thống plugin.

Mặc dù bạn có thể tìm thấy ctypes để làm việc với 2.3/2.4, chúng không được đóng gói chính thức.

Vì vậy, đề xuất của tôi sẽ là 2,5.

Answer 3

Công ty của tôi được chuẩn hóa ở 2.5. Cũng giống như bạn, chúng tôi không thể chuyển sang 3.0 vì một triệu lý do, nhưng tôi rất muốn chúng tôi có thể lên tới 2.6.

Làm mã hóa ngày này sang ngày tôi sẽ xem xét thông qua các tài liệu hướng dẫn và tôi sẽ tìm thấy chính xác các mô-đun hoặc chức năng mà tôi muốn, nhưng sau đó nó sẽ có chú thích nhỏ: mới trong phiên bản 2,6

tôi sẽ nói đi với các phiên bản mới nhất, và nếu bạn có cảnh báo khấu hao bật lên (có lẽ sẽ có rất ít) sau đó chỉ cần đi trong một tìm một cách tốt hơn để làm điều đó. Nói chung mã của bạn sẽ tốt hơn với 2.6.

Answer 4

Chúng tôi đang gắn bó với 2.5.2 ngay bây giờ. Stack công nghệ của chúng tôi trung tâm trên Django (nhưng chúng tôi có một chục bit khác và bobs.) Vì vậy, chúng tôi ở gần với những gì họ làm.

Chúng tôi phải quay lại docutils thành 0,4 để nó hoạt động với epydoc 3.0.1. Cho đến nay, đây không phải là một vấn đề lớn, nhưng nó có thể - vào một thời điểm nào đó - khiến chúng ta suy nghĩ lại việc sử dụng epydoc.

Nâng cấp 2.6 là một phần trong kế hoạch phát triển của chúng tôi. Chúng tôi có ngân sách nhưng không phải là lịch biểu cố định ngay bây giờ.

Nâng cấp 3.0, tương tự, là điều tôi nhắc nhở mọi người. Chúng ta phải ngân sách cho nó. Chúng tôi sẽ không làm điều đó trong năm nay trừ khi Django nhảy tới 3.0. Chúng ta có thể làm điều đó vào năm tới.

Answer 5

Tôi nghĩ giải pháp tốt nhất là từ bỏ hy vọng về tính đồng nhất, mặc dù có một môi trường chung là điều gì đó để phấn đấu. Bạn sẽ luôn phải đối mặt với các vấn đề về phiên bản, ví dụ như khi nâng cấp lên phiên bản phiên dịch tốt nhất tiếp theo.

Vì vậy, thay vì giải quyết vấn đề này trên cơ sở từng vấn đề, bạn có thể giải quyết vấn đề này bằng cách xem xét kỹ về quản lý phát hành của mình.

Thay vì phát hành nguồn, hãy tìm nền tảng tùy thuộc vào nhị phân (ngoài phân phối nguồn).

Vì vậy, những gì bạn làm là bạn xác định một số hỗ trợ CPU của, ví dụ: x86-32, x86-64, sparc

Sau đó, mà các hệ điều hành: Linux, Windows, Solaris, FreeBSD

Đối với mỗi hệ điều hành, bạn hỗ trợ một số phiên bản chính của chúng.

Bước tiếp theo là bạn cung cấp tệp nhị phân cho tất cả chúng.

Có thực sự điều này sẽ yêu cầu khá một số đầu tư cơ sở hạ tầng và thiết lập tòa nhà tự động từ kho của bạn (bạn có chúng?).

Ưu điểm là người dùng của bạn chỉ có cài đặt 'một' và bạn có thể dễ dàng chuyển đổi phiên bản hoặc thậm chí là trộn phiên bản. Trên thực tế, bạn thậm chí có thể sử dụng các ngôn ngữ lập trình khác nhau với phương pháp này mà không ảnh hưởng đến quá trình quản lý phát hành của bạn quá nhiều.