Các gói Python thường được lưu trữ trong kho của nhiều bản phân phối. Sau khi đọc hướng dẫn này , cụ thể là phần có tiêu đề "Bạn có thực sự muốn làm việc này không" Tôi đã tránh sử dụng pip và ưu tiên sử dụng kho lưu trữ hệ thống, chỉ dùng đến pip khi tôi cần cài đặt gói không có trong kho.

Tuy nhiên, vì đây là phương pháp cài đặt không nhất quán, nên sử dụng pip sẽ tốt hơn? Những lợi ích / gièm pha khi sử dụng pip trên kho lưu trữ riêng của hệ thống đối với các gói có sẵn ở cả hai nơi là gì?

Liên kết tôi bao gồm các tiểu bang

Ưu điểm của việc luôn sử dụng các gói Debian / NeuroDebian tiêu chuẩn là các gói được kiểm tra cẩn thận để tương thích với nhau. Các gói Debian ghi lại các phụ thuộc với các thư viện khác, do đó bạn sẽ luôn nhận được các thư viện bạn cần như một phần của bản cài đặt.

Tôi sử dụng vòm. Đây có phải là trường hợp với các hệ thống quản lý gói khác ngoài apt?

Nhược điểm lớn nhất tôi thấy khi sử dụng pipđể cài đặt các mô-đun Python trên hệ thống của bạn, dưới dạng mô-đun hệ thống hoặc mô-đun người dùng, là hệ thống quản lý gói phân phối của bạn sẽ không biết về chúng. Điều này có nghĩa là chúng sẽ không được sử dụng cho bất kỳ gói nào khác cần chúng và bạn có thể muốn cài đặt trong tương lai (hoặc có thể bắt đầu sử dụng một trong các mô-đun đó sau khi nâng cấp); sau đó bạn sẽ kết thúc với cả hai pip- và các phiên bản mô-đun được quản lý phân phối, có thể gây ra sự cố (tôi đã gặp một trường hợp khác của điều này gần đây). Vì vậy, câu hỏi của bạn kết thúc là một đề xuất tất cả hoặc không có gì: nếu bạn chỉ sử dụngpip đối với các mô-đun Python, bạn không còn có thể sử dụng trình quản lý gói phân phối của mình cho bất kỳ điều gì muốn sử dụng mô-đun Python ...

Lời khuyên chung được đưa ra trong trang bạn liên kết là rất tốt: hãy cố gắng sử dụng các gói phân phối của bạn càng nhiều càng tốt, chỉ sử dụng pipcho các mô-đun không được đóng gói và khi bạn thực hiện, hãy làm như vậy trong thiết lập người dùng của bạn chứ không phải hệ thống- rộng. Sử dụng môi trường ảo càng nhiều càng tốt, đặc biệt là để phát triển mô-đun. Đặc biệt trên Arch, bạn không nên gặp phải các vấn đề gây ra bởi các mô-đun cũ hơn; ngay cả trên các bản phân phối có thể là một vấn đề, môi trường ảo xử lý nó khá dễ dàng.

Luôn luôn đáng xem xét rằng các gói thư viện và mô-đun phân phối được đóng gói chủ yếu để sử dụng các gói khác trong phân phối; có chúng xung quanh là một hiệu ứng phụ tuyệt vời để phát triển bằng cách sử dụng các thư viện và mô-đun đó, nhưng đó không phải là trường hợp sử dụng chính.

TL; DR

• sử dụng pip(+ virtualenv) cho công cụ (libs, khung, có thể là công cụ dev) các dự án của bạn (mà bạn phát triển) sử dụng
• sử dụng trình quản lý gói cho các ứng dụng bạn sử dụng (với tư cách là người dùng cuối)

Phụ thuộc phát triển

Nếu bạn đang phát triển phần mềm bằng Python, bạn sẽ muốn sử dụng pipcho tất cả các phụ thuộc của dự án, có thể là phụ thuộc thời gian chạy, phụ thuộc thời gian xây dựng hoặc công cụ cần thiết để kiểm tra tự động và kiểm tra tuân thủ tự động (kẻ nói dối, trình kiểm tra kiểu, trình kiểm tra kiểu tĩnh ...)

Cái này có một vài nguyên nhân:

• Điều này cho phép bạn sử dụng virtualenv (trực tiếp hoặc thông qua virtualenvwrapper hoặc pipenv hoặc các phương tiện khác) để tách các phụ thuộc của các dự án khác nhau và tách biệt các ứng dụng python mà bạn sử dụng "trong sản xuất" (với tư cách là người dùng) khỏi bất kỳ shenanigans kỳ lạ nào (hoặc người dùng) thậm chí chỉ là không tương thích) có thể tiếp tục phát triển.
• Điều này cho phép bạn theo dõi tất cả các phụ thuộc của dự án trong một tệp requirements.txt(nếu dự án của bạn là một ứng dụng) hoặc setup.py(nếu dự án của bạn là một thư viện hoặc khung). Điều này có thể được kiểm tra trong kiểm soát sửa đổi (ví dụ Git) cùng với mã nguồn, để bạn luôn biết phiên bản mã nào của bạn dựa vào phiên bản phụ thuộc nào của bạn.
• Những điều trên cho phép các nhà phát triển khác cộng tác trong dự án của bạn ngay cả khi họ không sử dụng cùng một bản phân phối Linux hoặc thậm chí không cùng hệ điều hành (nếu phụ thuộc được sử dụng cũng có sẵn trên Mac và Windows hoặc bất cứ điều gì họ sử dụng, đó là)
• Bạn không muốn cập nhật tự động trình quản lý gói của hệ điều hành để phá mã của bạn. Bạn nên cập nhật các phụ thuộc của mình, nhưng bạn nên thực hiện một cách có ý thức và vào những lúc bạn chọn, để bạn có thể sẵn sàng sửa mã của mình hoặc khôi phục lại bản cập nhật. (Thật dễ dàng nếu bạn theo dõi khai báo phụ thuộc hoàn chỉnh trong hệ thống kiểm soát sửa đổi, cùng với mã của bạn.)

Nếu bạn cảm thấy cần tách riêng các phụ thuộc trực tiếp và gián tiếp (hoặc phân biệt giữa phạm vi phiên bản có thể chấp nhận cho phiên bản phụ thuộc và phiên bản thực tế được sử dụng, hãy xem "ghim phiên bản") xem xét các công cụ pip và / hoặc pipenv. Điều này cũng sẽ cho phép bạn phân biệt giữa phụ thuộc xây dựng và thử nghiệm. (Sự khác biệt giữa phụ thuộc vào xây dựng và thời gian chạy có thể được mã hóa trong setup.py)

Ứng dụng bạn sử dụng

Đối với những thứ bạn sử dụng như ứng dụng thông thường và tình cờ được viết bằng Python, hãy ưu tiên trình quản lý gói của hệ điều hành của bạn. Nó sẽ đảm bảo nó luôn cập nhật hợp lý và tương thích với các nội dung khác được cài đặt bởi trình quản lý gói. Hầu hết các bản phân phối Linux cũng sẽ khẳng định rằng họ không phân phối bất kỳ phần mềm độc hại nào.

Nếu thứ gì đó bạn cần không có sẵn trong repo gói mặc định của phân phối, bạn có thể kiểm tra repos gói bổ sung (ví dụ: launchpad của các bản phân phối dựa trên deb) hoặc sử dụng bằng pipmọi cách. Nếu sau này, hãy sử dụng --userđể cài đặt vào nhà của người dùng thay vì toàn hệ thống, để bạn ít có khả năng phá vỡ cài đặt Python của mình. (Đối với những thứ bạn chỉ cần tạm thời hoặc hiếm khi, bạn thậm chí có thể sử dụng virtualenv.)

Một lý do khác để đi với trình quản lý gói là các bản cập nhật sẽ được tự động áp dụng, điều này rất quan trọng đối với bảo mật. Hãy suy nghĩ nếu gói đậu mà Equachus sử dụng đã được cập nhật tự động thông qua bảo mật yum-cron, thì vụ hack có thể đã không xảy ra.

Trên hộp dev cá nhân của tôi, tôi sử dụng Pip, trong prod tôi sử dụng các gói.

Nếu chúng ta đang nói về việc cài đặt các gói python để sử dụng trong mã bạn đang viết, hãy sử dụng pip.

Đối với mỗi dự án bạn đang làm việc, hãy tạo một môi trường ảo và sau đó chỉ sử dụng pip để cài đặt những thứ mà dự án cần. Bằng cách đó, bạn cài đặt tất cả các thư viện bạn sử dụng một cách nhất quán và chúng được chứa và không can thiệp vào bất cứ điều gì bạn cài đặt thông qua trình quản lý gói của bạn.

Thông thường, nếu bạn dự định phát hành bất kỳ mã python nào, bạn sẽ thêm một setup.pyhoặc requirements.txtvào dự án của mình, điều này sẽ cho phép pip tự động nhận tất cả các phụ thuộc của nó. Cho phép bạn dễ dàng tạo hoặc tạo lại môi trường ảo cho dự án đó.

Tóm lược

Có ba loại mô-đun chung mà bạn đang xử lý:

1. Những chương trình hỗ trợ được cài đặt cho tất cả người dùng với hệ thống gói HĐH. (Điều này thậm chí có thể bao gồm các công cụ và thư viện được sử dụng bởi những người lập trình trong Python; xem bên dưới.) Đối với những công cụ này, bạn sử dụng các gói hệ điều hành nơi bạn có thể và pipcài đặt vào các thư mục hệ thống khi cần thiết.
2. Các chương trình hỗ trợ được cài đặt bởi một người dùng cụ thể chỉ cho mục đích sử dụng của riêng cô ấy và cho các khía cạnh nhất định của việc sử dụng Python "hàng ngày" của cô ấy làm ngôn ngữ kịch bản. Đối với những thứ cô ấy sử dụng pip --user, có lẽ là pyenv hoặc pythonz , và các công cụ và chiến thuật tương tự.
3. Những người hỗ trợ phát triển và sử dụng một ứng dụng cụ thể. Đối với những bạn sử dụng virtualenv(hoặc một công cụ tương tự).

Mỗi cấp độ ở đây cũng có thể nhận được hỗ trợ từ cấp độ trước. Ví dụ: người dùng của chúng tôi trong (2) có thể đang dựa vào trình thông dịch Python được cài đặt qua các gói hệ điều hành.

Đi sâu vào vấn đề này chi tiết hơn một chút:

Chương trình và gói hệ thống

Các chương trình được viết bằng Python mà bạn muốn "chỉ chạy" rất dễ dàng: chỉ cần sử dụng các công cụ cài đặt hệ điều hành và để chúng mang lại bất cứ thứ gì chúng cần; điều này không khác với một chương trình không phải là Python. Điều này có khả năng mang lại các công cụ / thư viện Python (chẳng hạn như trình thông dịch Python!) Mà người dùng trên máy của bạn có thể bắt đầu dựa vào; đây không phải là vấn đề miễn là họ hiểu được sự phụ thuộc và, lý tưởng nhất là biết các phương tiện thay thế để xử lý nó trên các máy chủ không cung cấp các phụ thuộc đó.

Một ví dụ phổ biến và đơn giản về sự phụ thuộc như vậy là một số tập lệnh cá nhân của tôi ~/.local/bin/bắt đầu bằng #!/usr/bin/env python. Chúng sẽ hoạt động tốt (miễn là chúng chạy trong Python 2) trên các bản cài đặt RH / CentOS 7 và hầu hết (nhưng không phải tất cả); chúng sẽ không cài đặt Debian cơ bản hoặc trên Windows. Nhiều khi tôi không thích môi trường cá nhân của mình có nhiều cách phụ thuộc vào các gói HĐH (tôi làm việc trên một số HĐH khác nhau), một cái gì đó như thế này tôi thấy khá dễ chấp nhận; kế hoạch sao lưu của tôi trên các máy chủ hiếm hoi không có Python hệ thống và không thể có được một hệ thống người dùng như được mô tả bên dưới.

Những người sử dụng trình thông dịch python hệ thống cũng thường phụ thuộc vào hệ thống pip3. Đó là về nơi tôi thường vẽ đường phụ thuộc vào hệ thống của mình; tất cả mọi thứ từ virtualenvphía trước tôi đối phó với chính mình. (Ví dụ: tập lệnh kích hoạt tiêu chuẩn của tôi phụ thuộc vào bất cứ thứ gì pip3hoặc pipnằm trong đường dẫn, nhưng tải xuống bản sao của chính nó virtualenvđể khởi động lại môi trường ảo mà nó tạo ra.

Điều đó nói rằng, có lẽ có những trường hợp hoàn toàn hợp lý để tạo thêm môi trường phát triển. Bạn có thể có các giao diện Python thành các gói phức tạp (chẳng hạn như DBMS) nơi bạn muốn sử dụng phiên bản hệ thống của nó và bạn cảm thấy tốt nhất là bạn cũng để hệ thống chọn mã thư viện Python cụ thể mà bạn sẽ sử dụng để nói chuyện với nó. Hoặc bạn có thể đang triển khai nhiều máy chủ lưu trữ với môi trường phát triển cơ bản cho lớp Python và thấy dễ dàng tự động hóa với các gói hệ thống tiêu chuẩn.

Các chương trình và gói "hàng ngày" của người dùng

Người dùng có thể có các thư viện hoặc chương trình Python không phù hợp với môi trường ảo vì họ muốn giúp tạo môi trường ảo ngay từ đầu (ví dụ: virtualenvwrapper ) hoặc chúng là những thứ bạn thường sử dụng từ dòng lệnh ngay cả khi làm công việc không phải Python. Ngay cả khi họ có khả năng cài đặt các phiên bản hệ thống này, họ có thể cảm thấy thoải mái hơn khi cài đặt phiên bản của riêng họ (ví dụ: vì họ muốn sử dụng phiên bản mới nhất của công cụ và các phụ thuộc của nó).

Nói chung pip --userlà những gì mọi người sẽ sử dụng cho việc này, mặc dù các phụ thuộc nhất định, chẳng hạn như trình thông dịch Python, yêu cầu nhiều hơn thế. pyenv và pythonz rất hữu ích để xây dựng trình thông dịch cá nhân (cho dù được cài đặt ~/.local/binlàm trình thông dịch mặc định hay nói cách khác), và tất nhiên người ta luôn có thể xây dựng "bằng tay" từ nguồn nếu có sẵn thư viện dev.

Tôi cố gắng giữ tập hợp tối thiểu của những thứ được cài đặt ở đây: virtualenvwrapper (vì tôi sử dụng nó liên tục) và có lẽ là phiên bản mới nhất của pip. Tôi cố gắng tránh các phụ thuộc bên ngoài thư viện chuẩn hoặc trên Python 3 cho các tập lệnh cá nhân mà tôi viết sẽ được sử dụng trên nhiều máy chủ. (Mặc dù chúng ta sẽ thấy tôi có thể giữ được điều đó trong bao lâu khi tôi chuyển ngày càng nhiều các tập lệnh cá nhân này sang Python.)

Phát triển ứng dụng và môi trường thời gian chạy riêng biệt

Đây là điều virtualenv thông thường. Để phát triển, bạn hầu như luôn luôn sử dụng virtualenv để đảm bảo rằng bạn không sử dụng các phụ thuộc hệ thống hoặc thường là nhiều hơn một để kiểm tra các phiên bản Python khác nhau.

Các môi trường ảo này cũng tốt cho các ứng dụng có nhiều phụ thuộc mà bạn muốn tránh làm ô nhiễm môi trường người dùng của mình. Ví dụ, tôi thường thiết lập một virtualenv để chạy sổ ghi chép Jupyter và những thứ tương tự.