cài đặt pip trong gói site toàn cầu thay vì virtualenv

Việc sử dụng pip3để cài đặt gói trong một virtualenvkhiến gói được cài đặt trong thư mục gói trang chung thay vì gói trong thư mục virtualenv. Đây là cách tôi thiết lập Python3 và virtualenv trên OS X Mavericks (10.9.1):

Tôi đã cài đặt Python3 bằng Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

Đã thay đổi $PATHbiến trong .bash_profile; đã thêm dòng sau:

export PATH=/usr/local/bin:$PATH

Chạy which python3trả lại/usr/local/bin/python3 (sau khi khởi động lại trình bao).

Lưu ý: which python3vẫn trả hàng /usr/bin/python mặc dù.

Được cài đặt virtualenvbằng pip3:

pip3 install virtualenv

Tiếp theo, tạo mới virtualenvvà kích hoạt nó:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Lưu ý: nếu tôi không chỉ định -p python3, pip sẽ bị thiếu trong thư mục bin trong virtualenv.

Đang chạy which pipvà which pip3cả hai đều trả về thư mục virtualenv:

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

Bây giờ, khi tôi cố gắng cài đặt, ví dụ: Markdown bằng cách sử dụng pip trong virtualenv đã được kích hoạt, pip sẽ cài đặt trong thư mục gói trang chung thay vì thư mục gói trang của virtualenv.

pip install markdown

Chạy pip listtrả về:

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

Nội dung của /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

Nội dung của /usr/local/lib/python3.3/site-packages:

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

Như bạn có thể thấy, thư mục gói trang toàn cầu chứa Markdown, thư mục virtualenv thì không.

Lưu ý: Tôi đã cài đặt Python2 và Python3 trước đó trên một máy ảo khác (làm theo các hướng dẫn sau) và gặp vấn đề tương tự với Python3; Tuy nhiên, việc cài đặt các gói trong virtualenv dựa trên Python2 hoạt động hoàn hảo.

Bất kỳ lời khuyên, gợi ý, ... sẽ được đánh giá rất cao.

Thật buồn cười khi bạn đưa ra điều này, tôi chỉ có cùng một vấn đề. Cuối cùng tôi đã giải quyết được nó, nhưng tôi vẫn không chắc về nguyên nhân gây ra nó.

Hãy thử kiểm tra tập lệnh bin/pipvà của bạn bin/activate. Trong bin/pip, hãy nhìn shebang. Nó có đúng không? Nếu không, hãy sửa lại. Sau đó, trên dòng ~ 42của bạn bin/activate, hãy kiểm tra xem đường dẫn virtualenv của bạn có đúng không. Nó sẽ giống như thế này

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

Nếu nó sai, sửa chữa nó, deactivatethì . bin/activate, và nếu vấn đề chung của chúng ta có cùng một nguyên nhân, cần làm việc. Nếu nó vẫn không, dù sao thì bạn cũng đang đi đúng hướng. Tôi đã trải qua cùng một quy trình giải quyết vấn đề như bạn đã làm, which piplặp đi lặp lại, theo dõi ngăn xếp, v.v.

Hãy chắc chắn rằng

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

là những gì bạn muốn và không đề cập đến một dự án thử nghiệm có tên tương tự khác (Tôi đã gặp sự cố đó và không biết nó bắt đầu như thế nào. Tôi nghi ngờ là chạy nhiều virtualenv cùng một lúc).

Nếu không có cách nào trong số này hiệu quả, một giải pháp tạm thời có thể là, như Joe Holloway đã nói,

Chỉ cần chạy pip của virtualenv với đường dẫn đầy đủ của nó (tức là không dựa vào việc tìm kiếm đường dẫn thực thi) và bạn thậm chí không cần kích hoạt môi trường. Nó sẽ làm điều đúng đắn.

Có lẽ không lý tưởng, nhưng nó sẽ hoạt động hiệu quả.

Liên kết đến câu hỏi ban đầu của tôi:

VirtualEnv / Pip đang cố gắng cài đặt các gói trên toàn cầu

Đối với tôi, đây không phải là vấn đề về pip hay virtualenv. Đó là một vấn đề về trăn. Tôi đã đặt $ PYTHONPATH theo cách thủ công trong ~ / .bash_profile (hoặc ~ / .bashrc) sau khi làm theo một số hướng dẫn trực tuyến. $ PYTHONPATH được thiết lập thủ công này đã có sẵn trong virtualenv vì nó có thể phải được cho phép.

Ngoài ra, tôi add2virtualenvđã không thêm đường dẫn dự án vào $ PYTHONPATH vì một số lý do trong virtualenv.

Chỉ là một số con đường rẽ nhánh cho những người có thể vẫn còn bị mắc kẹt! Chúc mừng!

Tôi đã gặp vấn đề tương tự, tôi đã giải quyết nó bằng cách xóa thư mục venv và tạo lại nó!

deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt

Bây giờ mọi thứ hoạt động như một cái duyên.

Tôi cũng có vấn đề này. Việc gọi pip install <package_name>từ /binthư mục trong môi trường ảo Python 3.3 của tôi trên máy Mac Mavericks của tôi đã khiến gói Python được cài đặt trong thư mục gói trang web toàn cầu Python 2.7. Điều này là mặc dù thực tế là $ PATH của tôi bắt đầu với thư mục chứa pip. Kỳ dị. Điều này không xảy ra trên CentOS. Đối với tôi, giải pháp là kêu gọi pip3thay vì pip. Khi tôi đã cài đặt pip trong môi trường ảo qua ez_setup , ba "pip" thực thi đã được cài đặt trong /binthư mục - pip, pip3, và pip3.3. Thật kỳ lạ, cả ba tệp đều hoàn toàn giống nhau. Kêu gọipip3 install <package_name>khiến gói Python được cài đặt chính xác vào thư mục gói trang cục bộ. Gọipipvới tên đường dẫn đầy đủ vào môi trường ảo cũng hoạt động chính xác. Tôi muốn biết tại sao máy Mac của tôi không sử dụng $ PATH theo cách tôi mong đợi.

Điều đầu tiên cần kiểm tra là vị trí pip đang giải quyết:

which pip

nếu bạn đang ở trong virtualenv, bạn sẽ mong đợi điều này cung cấp cho bạn một cái gì đó như:

/path/to/virtualenv/.name_of_virtualenv/bin/pip

Tuy nhiên có thể có trường hợp nó phân giải thành pip hệ thống của bạn vì một số lý do. Ví dụ: bạn có thể thấy điều này từ bên trong virtualenv của mình (điều này rất tệ):

/ usr / local / bin / pip (hoặc bất kỳ thứ gì không có trong đường dẫn virtualenv của bạn).

Để giải quyết vấn đề này, hãy kiểm tra pipconfig của bạn trong:

~/.pipconf
~/.conf/pip
/etc/pip.conf

và đảm bảo rằng không có gì ép buộc đường dẫn Python hoặc đường dẫn pip của bạn (điều này đã sửa lỗi cho tôi).

Sau đó, hãy thử khởi động một thiết bị đầu cuối mới và xây dựng lại virtualenv của bạn (xóa rồi tạo lại)

Tôi gặp phải vấn đề tương tự khi cài đặt gói python từ bên trong virtualenv. Nguyên nhân gốc rễ trong trường hợp của tôi là khác nhau. Từ bên trong virtualenv, tôi đã (không quen với Ubuntu), làm:

sudo easy_install -Z <package>

Điều này khiến bin / pip shebang bị bỏ qua và nó sử dụng python không phải virtualenv của gốc để cài đặt nó trong gói trang web toàn cầu. Vì chúng ta có một môi trường ảo, chúng ta nên cài đặt gói không có "sudo"

Tôi đã vấp phải vấn đề tương tự khi điều hành Manjaro. Tôi đã tạo môi trường ảo bằng cách sử dụng python3 -m ven venvvà sau đó kích hoạt bằng cách sử dụng source venv/bin/actiave. which pythonvà which pipcả hai đều trỏ tới các tệp nhị phân chính xác trong virtualenv, tuy nhiên tôi không thể cài đặt vào virtualenv, ngay cả khi sử dụng đường dẫn đầy đủ của các tệp nhị phân. Hóa ra là khi tôi gỡ cài đặt gói python-pip với sudo pacman -R python-pip python-reportlab(phải bao gồm reportlab để đáp ứng các phụ thuộc) mọi thứ bắt đầu hoạt động như mong đợi. Không chắc tại sao, nhưng điều này có thể là do cài đặt kép trong đó gói hệ thống được ưu tiên.

Tôi đã gặp sự cố tương tự sau khi cập nhật lên pip==8.0.0. Đã phải dùng đến gỡ lỗi pip để tìm ra đường dẫn xấu.

Hóa ra thư mục hồ sơ của tôi có một tệp cấu hình distutils với một số giá trị đường dẫn trống. Điều này khiến tất cả các gói được cài đặt vào cùng một thư mục gốc thay vì môi trường ảo thích hợp (trong trường hợp của tôi /lib/site-packages).

Tôi không chắc làm thế nào tệp cấu hình đến đó hoặc làm thế nào nó có các giá trị trống nhưng nó bắt đầu sau khi cập nhật pip.

Trong trường hợp bất kỳ ai khác gặp phải vấn đề tương tự này, chỉ cần xóa tệp ~/.pydistutils.cfg(hoặc xóa đường dẫn cấu hình trống) đã khắc phục sự cố trong môi trường của tôi vì pip đã quay trở lại cấu hình phân phối mặc định.

Đi tới thư mục bin trong môi trường ảo của bạn và viết như sau:

./pip3 install <package-name>

Tôi đã gặp vấn đề tương tự trên macos có cài đặt python 2 và 3.

Ngoài ra, tôi có bí danh để trỏ đến python3 và pip3 trong của tôi .bash_profile.

alias python=/usr/local/bin/python3
alias pip=/usr/local/bin/pip3

Xóa bí danh và tạo lại env ảo bằng cách sử dụng đã python3 -m venv venvkhắc phục sự cố.

Đã đến cùng một vấn đề ngày hôm nay. Tôi chỉ cần cài đặt lại pip trên toàn cầu với sudo easy_install pip(OSX / Max), sau đó tạo lại virtualenv với sudo virtualenv nameOfVEnv. Sau đó, sau khi kích hoạt virtualenv mới, piplệnh hoạt động như mong đợi.

Tôi không nghĩ rằng tôi đã sử dụng sudotrong lần tạo virtualenv đầu tiên và đó có thể là lý do không có quyền truy cập piptừ bên trong virtualenv, tôi đã có thể truy cập pip2trước khi sửa lỗi này mặc dù điều đó thật kỳ lạ.

Dưới đây là một số phương pháp có thể tránh đau đầu khi sử dụng Môi trường ảo:

• Tạo một thư mục cho các dự án của bạn.
• Tạo các dự án Virtualenv của bạn bên trong thư mục này.
• Sau khi kích hoạt môi trường của dự án của bạn, không bao giờ sử dụng " sudo pip install package ".
• Sau khi hoàn thành công việc của bạn, luôn luôn " tắt " môi trường của bạn.
• Tránh đổi tên thư mục dự án của bạn.

Để trình bày tốt hơn các thực hành này, đây là một mô phỏng:

tạo một thư mục cho các dự án / môi trường của bạn

$ mkdir venv

tạo môi trường

$ cd venv/ 

$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.

môi trường kích hoạt

$ source google_drive/bin/activate

cài đặt các gói

(google_drive) $ pip install PyDrive
Downloading/unpacking PyDrive
Downloading PyDrive-1.3.1-py2-none-any.whl
...
...
...    
Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules
Cleaning up...

gói có sẵn bên trong môi trường

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
>>>  
>>> gdrive = pydrive.auth.GoogleAuth()
>>>

hủy kích hoạt môi trường

(google_drive) $ deactivate 

$ 

gói KHÔNG CÓ sẵn bên ngoài môi trường

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:32:10) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pydrive.auth
>>> 

Ghi chú:

Tại sao không sudo?

Virtualenv tạo ra một môi trường hoàn toàn mới cho bạn, xác định $ PATH và một số biến và cài đặt khác. Khi bạn sử dụng sudo pip cài đặt gói , bạn đang chạy virtualenv như rễ , thoát toàn bộ môi trường mà đã được tạo ra, và sau đó, cài đặt gói trên toàn cầu site-packages, và không bên trong thư mục dự án , nơi bạn có một môi trường ảo, mặc dù bạn đã kích hoạt môi trường.

Nếu bạn đổi tên thư mục của dự án của mình (như đã đề cập trong câu trả lời được chấp nhận) ...

... bạn sẽ phải điều chỉnh một số biến từ một số tệp bên trong thùng thư mục của dự án của bạn.

Ví dụ:

bin / pip, dòng 1 (She Bang)

bin / kích hoạt, dòng 42 (VIRTUAL_ENV)

Tôi đã có vấn đề này. Hóa ra có một khoảng trống trong một trong các tên thư mục của tôi gây ra sự cố. Tôi đã xóa không gian, xóa và khôi phục bằng cách sử dụng venv, và tất cả đều ổn.

Sự cố này xảy ra khi tạo một phiên bản virtualenv và sau đó thay đổi tên thư mục mẹ.

Không có giải pháp nào ở trên phù hợp với tôi.

Venv của tôi đã hoạt động. pip -Vvà which pipcung cấp cho tôi đường dẫn virtualenv chính xác, nhưng khi tôi pip install-ed các gói có venv được kích hoạt, của tôi pip freezevẫn trống.

Tất cả các biến môi trường cũng đúng.

Cuối cùng, tôi chỉ cần thay đổi pip và xóa virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Cài đặt lại venv:

sudo pip install virtualenv

Tạo venv:

python -m virtualenv venv_name_here

Và tất cả các gói được cài đặt chính xác vào venv của tôi một lần nữa.

Sau khi tạo môi trường ảo, hãy thử sử dụng pip nằm trong yourVirtualEnvName \ Scripts

Nó sẽ cài đặt một gói bên trong Lib \ site-package trong môi trường ảo của bạn

Tôi cũng có vấn đề này. Việc gọi sudo pip installlàm cho các gói Python được cài đặt trong thư mục gói trang toàn cầu và việc gọi pip installhoạt động tốt. Vì vậy, không sử dụng sudo trong virtualenv.

Vấn đề giống nhau. Python3.5 và pip 8.0.2 được cài đặt từ Linux rpm.

Tôi không tìm thấy nguyên nhân chính và không thể đưa ra câu trả lời thích hợp. Có vẻ như có nhiều nguyên nhân có thể xảy ra.

Tuy nhiên, tôi hy vọng tôi có thể giúp chia sẻ quan sát của mình và cách giải quyết.

1. pyvenv với --system-site-packages

   • ./binkhông chứa pip, pipcó sẵn từ các gói trang hệ thống
   • các gói được cài đặt trên toàn cầu ( BUG? )

2. pyvenv không có --system-site-packages

   • pipđược cài đặt vào ./bin, nhưng đó là một phiên bản khác (từ ensurepip)
   • các gói được cài đặt trong môi trường ảo ( OK )

Cách giải quyết rõ ràng cho pyvenvvới --system-site-packages:

• tạo nó mà không có --system-site-packagestùy chọn
• thay đổi include-system-site-packages = falseđể truetrong pyvenv.cfgtập tin

Cũng cần kiểm tra rằng bạn đã không sửa đổi bằng cách nào đó đường dẫn đến virtualenv của mình.

Trong trường hợp đó, dòng đầu tiên trong bin/pip(và phần còn lại của các tệp thực thi) sẽ có đường dẫn không chính xác.

Bạn có thể chỉnh sửa các tệp này và sửa đường dẫn hoặc xóa và cài đặt lại virtualenv.

Đối với Python 3ers

Hãy thử cập nhật. Tôi đã gặp vấn đề chính xác này và đã thử câu trả lời của Chases, tuy nhiên không thành công. Cách nhanh nhất để cấu trúc lại điều này là cập nhật phiên bản Python Minor / Patch của bạn nếu có thể. Tôi nhận thấy rằng tôi đang chạy 3.5.1 và cập nhật lên 3.5.2. Pyvenv một lần nữa hoạt động.

Điều này đã xảy ra với tôi khi tôi tạo virtualenv ở sai vị trí. Sau đó, tôi nghĩ rằng tôi có thể di chuyển dir đến một vị trí khác mà nó không quan trọng. Nó quan trọng.

mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]

Ồ, tôi đã quên cd vào projectstrước khi tạo virtualenv và nhân bản đại diện. Mà thôi, tôi quá lười để phá hủy và tái tạo. Tôi sẽ chỉ dir dir mà không có vấn đề gì.

cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements

Không, muốn nhiều quyền hơn, những gì? Tôi nghĩ nó là lạ nhưng SUDO AWAY! Sau đó, nó đã cài đặt các gói vào một vị trí toàn cầu.

Bài học tôi rút ra là, chỉ cần xóa dir virtualenv. Đừng di chuyển nó.

Gặp sự cố này sau khi cài đặt Divio: nó đã thay đổi PATH hoặc môi trường của tôi theo một cách nào đó, khi nó khởi chạy một thiết bị đầu cuối.

Giải pháp trong trường hợp này chỉ là làm những gì source ~/.bash_profileđã được thiết lập để đưa bạn trở lại trạng thái pyenv / pyenv-virtualenv ban đầu.

Điều đó xảy ra với tôi khi tôi cài đặt virtualenv với --python=python3.6cờ nhưng sau đó cố gắng sử dụng pip2 install.
Tạo virtualenv với cờ của phiên bản mà bạn sẽ sử dụng sẽ giải quyết các vấn đề về quyền. Để kiểm tra, hãy thử which piphoặc which pip2hoặc which pip3(tùy thuộc vào sự lựa chọn của bạn). Nếu bất kỳ pipbạn sử dụng cho thấy đường dẫn không đến venvđây là vấn đề của bạn.

Bằng cách nào đó, một tệp setup.cfg có tiền tố = "" trong thư mục dự án

chạy pip cài đặt trên virtualenv bên ngoài thư mục dự án đã hoạt động nên từ bên trong nó đã thông báo cho pip sử dụng tiền tố trống được mặc định là "/"

xóa tệp đã sửa nó

Tôi đã gặp sự cố này và sau khi thử tất cả các giải pháp trên, tôi chỉ xóa mọi thứ và bắt đầu lại.

Trong trường hợp của riêng tôi, tôi đã sử dụng sudođể tạo một trong các thư mục trong đó môi trường ảo tồn tại và sudo cung cấp cho các priviledges để root

Tôi đã rất tức giận! Nhưng nó đã hoạt động!

Tôi phải sử dụng 'sudo' để cài đặt các gói thông qua pip trên hệ thống ubuntu của mình vì một số lý do. Điều này làm cho các gói được cài đặt trong gói trang web toàn cầu. Đặt điều này ở đây cho bất kỳ ai có thể gặp phải vấn đề này trong tương lai.

Tôi đã gặp chính xác vấn đề từ tiêu đề, và tôi đã giải quyết nó. Pip bắt đầu cài đặt trong gói site venv sau khi tôi làm sạch PATH của mình: nó có đường dẫn đến thư mục ~ / bin cục bộ của tôi ngay từ đầu.

Vì vậy, lời khuyên của tôi: hãy kiểm tra kỹ lưỡng các biến môi trường của bạn xem có "rác" hoặc bất kỳ thứ không chuẩn nào không. Thật không may, virtualenv có thể nhạy cảm với những điều đó.

Chúc may mắn!

Câu trả lời ngắn gọn là chạy Command virtualenv với tham số “—no-site-pack”.

Câu trả lời dài kèm theo giải thích: -

Vì vậy, sau khi chạy ở đây và ở đó, và xem qua rất nhiều chủ đề, tôi đã tìm ra vấn đề của bản thân. Các câu trả lời trên đã đưa ra ý tưởng nhưng tôi muốn xem lại mọi thứ.

• Vấn đề là ngay cả khi bạn đang kích hoạt môi trường, nó đang đề cập đến môi trường hệ thống vì cách chúng ta đã tạo ra virtualenv.

• khi chúng ta chạy lệnh virtualenv env -p python3, nó sẽ cài đặt virtualenv nhưng nó sẽ không tạo no-global — site- Package.txt .

• Do đó, khi bạn kích hoạt môi trường bằng lệnh kích hoạt mã nguồn, tệp này có tên là site.py (tên có thể khác, tôi chỉ quên) chạy và kiểm tra nếu tệp này không có mặt, nó sẽ không thêm đường dẫn env của bạn vào sys.path và sử dụng python hệ thống.

• để khắc phục sự cố này, chỉ cần chạy virtualenv với tham số bổ sung —no-site-pack, nó sẽ tạo tệp đó và khi bạn kích hoạt môi trường, nó sẽ thêm đường dẫn môi trường tùy chỉnh của bạn trong biến PATH để có thể truy cập được.

Rất nhiều cuộc thảo luận tốt ở trên, nhưng các ví dụ về virtualenv đã được sử dụng. Vì 'conda' hiện là công cụ được khuyến nghị để quản lý virtualenv, tôi đã tóm tắt các bước trong việc chạy pip trong conda env như sau.

Tôi sẽ sử dụng py36r làm tên của env và / opt / conda / envs là tiền tố của env):

$ source /opt/conda/etc/profile.d/conda.sh # skip if already done 
$ conda activate py36r
$ pip  install pkg_xyz
$ pip  list | grep pkg_xyz

Lưu ý rằng pip được thực thi phải nằm trong /opt/conda/envs/py36r/bin/pip(không phải /opt/conda/bin/pip).

Ngoài ra, bạn có thể chỉ cần chạy phần sau mà không cần kích hoạt conda

$ /opt/conda/envs/py36r/bin/pip

Ngoài ra, nếu bạn cài đặt bằng conda, bạn có thể cài đặt mà không cần kích hoạt:

$ conda install -n py36r pkg_abc ...

CÁC CỬA SỔ

Đối với tôi giải pháp không được sử dụng mkvirtualenv, nhưng:

python -m venv path/to/your/virtualenv

workon hoạt động chính xác.

while trong virtualenv: pip -Vhiển thị đường dẫn đến pip của virtualenv