2009-11-10 20 views
6

Một vấn đề nảy sinh trong quá trình phát triển Pinax là xử lý các phiên bản phát triển của các ứng dụng bên ngoài. Tôi đang cố gắng đưa ra một giải pháp không liên quan đến việc đưa vào các hệ thống kiểm soát phiên bản. Lý do là tôi không muốn phải cài đặt tất cả các hệ thống kiểm soát phiên bản có thể có trên hệ thống của tôi (hoặc ép buộc khi đóng góp) và giải quyết các vấn đề có thể phát sinh trong quá trình tạo môi trường.Tôi có thể xử lý các phiên bản phát triển của các gói Python mà không cần dựa vào SCM như thế nào?

Đi tình trạng này (biết làm thế nào Pinax làm việc sẽ có lợi cho sự hiểu biết):

Chúng tôi đang bắt đầu phát triển trên một phiên bản mới của Pinax. Phiên bản trước có tệp yêu cầu pip với các phiên bản rõ ràng được đặt. Một lỗi xuất hiện trong ứng dụng bên ngoài mà chúng tôi muốn được giải quyết. Để sửa lỗi đó trong Pinax, quá trình hiện tại chỉ đơn giản là tạo một bản phát hành nhỏ của ứng dụng giả sử chúng ta có quyền kiểm soát ứng dụng. Ứng dụng chúng tôi không có quyền kiểm soát, chúng tôi chỉ giải quyết chu kỳ phát hành của tác giả ứng dụng hoặc buộc họ tạo bản phát hành ;-) Tôi không quá liên tục phát hành bản sửa lỗi nhỏ như trong một số trường hợp tôi muốn cũng làm việc trên các tính năng mới cho ứng dụng. Tất nhiên phân nhánh phiên bản cũ là những gì chúng ta làm và sau đó làm backports như chúng ta cần.

Tôi rất muốn nghe một số suy nghĩ về điều này.

+0

"Tôi không phải là quá ngây thơ không ngừng tạo các bản nhạc nhẹ cho sửa lỗi ..." "Dĩ nhiên là nhánh phiên bản cũ hơn là những gì chúng tôi làm ..." Chỉ cần được rõ ràng, bạn đang nói về ứng dụng hoặc chính Pinax (hoặc cả hai)? –

+0

Tôi đang đề cập đến các ứng dụng. Sau đó, chúng tôi chỉ nhắm mục tiêu bản phát hành nhỏ mới trong các yêu cầu của chúng tôi đối với phiên bản dành cho nhà phát triển và đáp ứng các yêu cầu nếu chúng tôi muốn phát hành phiên bản nhỏ của bản phát hành trước đó của Pinax. –

Trả lời

3

Tôi muốn đề cập đến giải pháp mà tôi đã cân nhắc trước khi yêu cầu là đưa lên một Pinax PyPI và phát hành bản phát hành trên đó. Chúng ta có thể đưa ra một thể hiện của chishop. Chúng tôi đã sử dụng pip's --find-links để trỏ đến pypi.pinaxproject.com cho các gói mà chúng tôi phải tự giải phóng.

+0

Bạn không chắc chắn nơi -1 đến từ, bất cứ ai quan tâm để giải thích? Với tôi điều này có vẻ như là lựa chọn tốt nhất có khả năng, vì nó cho phép kiểm soát nhiều hơn so với điều == dev mà tôi đã đề cập trong câu trả lời của mình. –

3

Bạn có thể xử lý điều này bằng cách sử dụng công cụ chỉ định phiên bản "== dev" không? Nếu trang phân phối trên PyPI bao gồm một liên kết đến một .tgz của phiên bản dev hiện tại (chẳng hạn như cả github và bitbucket cung cấp tự động) và bạn nối thêm "# egg = project_name-dev" vào liên kết, cả easy_install và pip sẽ sử dụng .tgz nếu == dev được yêu cầu.

Điều này không cho phép bạn ghim vào bất kỳ điều gì cụ thể hơn "mẹo/đầu gần đây nhất", nhưng trong nhiều trường hợp có thể đủ tốt?

1

Hầu hết các nhà phân phối nguồn mở (Debians, Ubuntu's, MacPorts, et al) đều sử dụng một số loại cơ chế quản lý bản vá. Vì vậy, một cái gì đó như: nhập mã nguồn cơ bản cho mỗi gói như được phát hành, dưới dạng bóng tar, hoặc dưới dạng ảnh chụp nhanh SCM. Sau đó, quản lý mọi sửa đổi cần thiết trên đầu trang bằng cách sử dụng trình quản lý bản vá, như quilt hoặc Mercurial's Queues. Sau đó gói từng gói bên ngoài với bất kỳ bản vá lỗi được áp dụng nào ở định dạng nhất quán. Hoặc có URL đến các gói cơ sở và URL cho các bản vá lỗi riêng lẻ và áp dụng chúng trong khi cài đặt. Đó chính là điều mà MacPorts thực hiện.

EDIT: Để thực hiện thêm một bước nữa, bạn có thể kiểm soát tập hợp các bản vá lỗi trên tất cả các gói bên ngoài và tạo rằng có sẵn dưới dạng đơn vị. Đó là khá dễ dàng để làm với hàng đợi Mercurial. Sau đó, bạn đã đơn giản hóa vấn đề chỉ xuất bản một bộ bản vá sử dụng một hệ thống SCM, với các bản vá được áp dụng cục bộ như trên hoặc có sẵn cho nhà phát triển để kéo và áp dụng cho bản sao của các gói phát hành cơ bản.

0

CHỈNH SỬA: Tôi không chắc chắn tôi đang đọc câu hỏi của bạn một cách chính xác vì vậy những điều sau đây có thể không trả lời câu hỏi của bạn trực tiếp.

Điều tôi đã xem xét, nhưng chưa thử nghiệm, đang sử dụng tính năng đóng băng của pip. Có lẽ sử dụng và phân phối các gói với Pinax sẽ làm việc? Mối quan tâm duy nhất của tôi là cách hệ điều hành khác nhau được xử lý. Ví dụ, tôi đã không bao giờ sử dụng pip trên Windows, vì vậy tôi sẽ không biết làm thế nào một gói sẽ tương tác ở đó.

Ý tưởng đầy đủ mà tôi hy vọng sẽ thử là tạo tập lệnh paver kiểm soát việc quản lý các gói, giúp người dùng dễ dàng nâng cấp lên phiên bản mới hơn. Điều này sẽ đòi hỏi một chút của giàn giáo mặc dù.

Một tùy chọn khác có thể là bạn giữ một tấm gương của các ứng dụng bạn không kiểm soát, trong một vcs nhất quán và sau đó phân phối các phiên bản được nhân đôi của bạn. Điều này sẽ lấy đi sự cần thiết cho "mọi người" để có nhiều chương trình khác nhau được cài đặt.

Ngoài ra, có vẻ như giải pháp thực sự duy nhất là những gì bạn đang làm, không có một cách rắc rối-miễn phí mà tôi đã có thể tìm thấy.

+0

Điều này sẽ phù hợp hơn với quá trình phát hành của Pinax. Hiện tại chúng tôi có một hệ thống được thiết lập khá tốt. Tuy nhiên, chúng tôi đã xem xét thử các gói pip cho bản phát hành. Nó vẫn còn trên bàn, nhưng chúng tôi đã không đưa ra quyết định nào về việc di chuyển theo cách đó. Đặc biệt vì bó pip là một tính năng rất thử nghiệm. –

+0

Vâng sau khi đọc lại câu hỏi của bạn Tôi thấy tôi không trả lời trực tiếp. –