Sử dụng các phiên bản khác nhau của thư viện python trong cùng một quá trình

Question

Chúng tôi đã có thư viện python mà chúng tôi đang phát triển. Trong quá trình phát triển, tôi muốn sử dụng một số phần của thư viện đó trong việc kiểm tra các phiên bản mới hơn của nó. Tức là, sử dụng mã ổn định để kiểm tra mã phát triển. Có cách nào để làm điều này trong python?

Chỉnh sửa: Cụ thể hơn, chúng tôi có một thư viện (LibA) có nhiều điều hữu ích. Ngoài ra, chúng tôi có một thư viện thử nghiệm sử dụng LibA để cung cấp một số cơ sở thử nghiệm (LibT). Chúng tôi muốn kiểm tra LibA bằng LibT, nhưng vì LibT phụ thuộc vào LibA, chúng tôi muốn sử dụng LibA phiên bản ổn định, trong khi thử nghiệm LibT (vì chúng tôi sẽ thay đổi LibT để làm việc với LibA mới hơn chỉ khi kiểm tra vượt qua vv). Vì vậy, khi chạy thử nghiệm đơn vị, các thử nghiệm LibA-dev sẽ sử dụng mã LibT phụ thuộc vào tính ổn định của LibA. Một ý tưởng mà chúng tôi đã đưa ra là gọi mã ổn định bằng RPyC trên một quy trình khác, nhưng thật khó để thực hiện theo cách không khí chặt chẽ (đảm bảo rằng nó chết đúng cách…) và cho phép nhiều phiên bản thực thi tại cùng một lúc trên cùng một máy tính vv).

Cảm ơn

Answer 1

Tôi không chắc chắn chính xác làm thế nào bạn cần phải thiết lập các bài kiểm tra của bạn, nhưng bạn có thể sử dụng VirtualEnv để có được cả hai trường hợp chạy dọc eachother.

Answer 2

Nếu bạn "thử nghiệm" libA-dev sử dụng libT phụ thuộc vào libA (ổn định), thì bạn không thực sự thử nghiệm libA-dev vì nó sẽ hoạt động trong môi trường sản xuất. Cách duy nhất để thực sự kiểm tra libA-dev là lấy đi toàn bộ và làm cho libT phụ thuộc vào libA-dev. Nếu điều này phá vỡ các bài kiểm tra đơn vị của bạn thì đó là một điều tốt - nó cho bạn thấy những gì cần phải được cố định.

Nếu bạn không có bài kiểm tra đơn vị, thì đây là lúc bắt đầu thực hiện chúng (sử dụng libA và libT ổn định trước!).

Tôi khuyên bạn nên sử dụng "hệ thống kiểm soát phiên bản" (ví dụ: bzr, hg, svn, git). Sau đó, bạn có thể tạo các nhánh của dự án, "ổn định" và "devA".

Để làm việc trên nhánh Deva, trước tiên bạn sẽ chạy

export PYTHONPATH=/path/to/devA 

Bằng cách đảm bảo các biến môi trường PYTHONPATH không bao gồm các ngành khác, bạn yên tâm Python được sử dụng chỉ các module mà bạn mong muốn.

Khi đến lúc hợp nhất mã từ dev -> ổn định, phần mềm điều khiển phiên bản cũng sẽ cung cấp cách dễ dàng để thực hiện điều đó.

Kiểm soát phiên bản cũng cho phép bạn mạnh hơn - thử những thay đổi lớn không đáng sợ. Nếu mọi thứ không hoạt động, việc hoàn nguyên sẽ trở nên cực kỳ dễ dàng. Giữa điều đó và thủ thuật PYTHONPATH, bạn luôn có thể trở lại với mã đã biết, đang hoạt động.

Nếu bạn cảm thấy ở trên chỉ đơn giản là không làm việc cho bạn, và bạn phải sử dụng libT-which-depends-on-libA để kiểm tra libA-dev, thì bạn cần phải đổi tên tất cả các mô-đun và sửa đổi tất cả các câu lệnh nhập khẩu để phân biệt rõ ràng giữa libA-dev và libA. Ví dụ, nếu libA có một mô-đun được gọi là moduleA.py, thì hãy đổi tên nó thành moduleA_dev.py.

Lệnh

rename -n 's/^(.*)\.py/$1_dev.py/' *.py 

sẽ thêm "_dev" cho tất cả các file * .py. (Với cờ "-n", lệnh đổi tên sẽ chỉ hiển thị cho bạn việc đổi tên dự tính. Hãy xóa "-n" để thực sự thực hiện với nó.)

Để trở lại việc đổi tên, chạy

rename -n 's/^(.*)_dev\.py/$1.py/' *.py 

Tiếp theo, bạn sẽ cần phải thay đổi tất cả các tham chiếu tới moduleA để moduleA_dev trong mã. Lệnh

find /path/to/LibA-dev/ -type f -name '*.py' -exec sed -i 's/moduleA/moduleA_dev/g' {} \; 

sẽ làm thay đổi tất cả các file * .py trong Liba-dev, thay đổi "moduleA" -> "moduleA_dev".

Hãy cẩn thận với lệnh này. Nó là nguy hiểm, bởi vì nếu bạn có một biến được gọi là moduleAB thì nó sẽ được đổi tên thành moduleA_devB, trong khi những gì bạn thực sự muốn có thể là moduleAB_dev.

Để trở lại sự thay đổi này (tùy thuộc vào sự báo trước ở trên),

find /path/to/LibA-dev/ -type f -name '*.py' -exec sed -i 's/moduleA_dev/moduleA/g' {} \; 

Khi bạn tách các không gian tên, bạn đã phá vỡ sự phụ thuộc tròn. Một khi bạn đã thỏa mãn libA-dev của bạn là tốt, bạn có thể thay đổi moduleA_dev.py -> moduleA.py và thay đổi tất cả các tham chiếu đến moduleA_dev -> moduleA trong mã của bạn.

Answer 3

"Chúng tôi muốn kiểm tra Liba sử dụng LIBT, nhưng vì LIBT phụ thuộc vào Liba, chúng tôi thà nó sử dụng một phiên bản ổn định của Liba, trong khi thử nghiệm LIBT"

Nó không có ý nghĩa để sử dụng T + A để kiểm tra A. Điều gì có ý nghĩa như sau.

LibA thực sự là hai thứ được trộn với nhau: A1 và A2.

T phụ thuộc vào A1.

Điều thực sự xảy ra là bạn đang nâng cấp và thử nghiệm A2, sử dụng T và A1.

Nếu bạn phân tách LibA thành các phần mà T yêu cầu và các phần khác, bạn có thể phá vỡ sự phụ thuộc vòng tròn này.