2016-01-01 20 views
6

PyCharm wydaje się ignorować skonfigurowany virtualenv, i zamiast tego używać interpretera bazowego.PyCharm nie używa wybranego virtualenv

W moim projekcie w /Users/janos/dev/git/github/bashoneliners mam podkatalog virtualenv ściśle z zainstalowanym zależności mojego projektu w tym:

$ . virtualenv/bin/activate 
(virtualenv)janos at kronos in ~/dev/git/github/bashoneliners on master 
$ pip -V 
pip 1.5.6 from /Users/janos/dev/git/github/bashoneliners/virtualenv/lib/python3.4/site-packages (python 3.4) 
(virtualenv)janos at kronos in ~/dev/git/github/bashoneliners on master 
$ pip freeze 
Django==1.9 
Markdown==2.6.5 
PyJWT==1.4.0 
defusedxml==0.4.1 
oauthlib==1.0.3 
pep8==1.6.2 
pyflakes==1.0.0 
python-social-auth==0.2.13 
python3-openid==3.0.9 
requests==2.9.1 
requests-oauthlib==0.6.0 
six==1.10.0 
tweepy==3.5.0 

Ale jeśli dodać tego interpretera virtualenv jak projektu w pycharm, pokazuje zupełnie inny pakiety:

enter image description here

Są paczka Wiek jest taki sam, jak w podstawowym tłumaczu mojego systemu /opt/local/bin/python. To doprowadza mnie do szału, naprawdę potrzebuję użyć pakietów z virtualenv, nie z mojego systemu.

To jest z PyCharm Community Edition 5.0.3.

Nie miałem tego problemu wcześniej ze starszymi wersjami PyCharm. Próbowałem utworzyć całkowicie nowy virtualenv, zarówno w wierszu poleceń i przy użyciu PyCharm, i unieważnianie pamięci podręcznych i ponowne uruchomienie, ale nic nie działa. PyCharm zawsze pokazuje tę samą listę pakietów, i paczek z virtualenv. Nawet jeśli utworzę pusty virtualenv w PyCharm, , nie będzie on pusty, ale wypełniony tą samą listą pakietów.

Mój projekt działa idealnie, gdy uruchamiam rzeczy w linii poleceń, , takie jak uruchamianie poleceń zarządzania Django, testy jednostkowe, wszystko. Mam tylko problemy w PyCharm.

Gdy próbuję zainstalować pakiety, na przykład Django użyciu pycharm, otrzymuję ten błąd:

enter image description here

Oczywiście uprawnien na /opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages, to interpreter systemu. Należy spróbować zainstalować pakiet tam, , ale w /Users/janos/dev/git/github/bashoneliners/virtualenv.

Oczywiście nie używa się pip z virtualenv, ale z systemu. Potrzebuję zrobić, aby użyć tego z virtualenv.

+0

Zalogowałeś się z youpackem jetbrains? – Sayse

+0

Czy wykluczasz pakiety globalne ze środowisk wirtualnych? – jonrsharpe

+0

@jonrsharpe Nie o tym wiem. Tworzę moje envs za pomocą 'virtualenv --distribute virtualenv'. Ale zaczynam myśleć, że problem może mieć coś wspólnego z tym, jak zainstalowałem Python (macports, ale nie pamiętam szczegółów). Na przykład, poza wirtualnym env, 'pip' nie jest zsynchronizowane z' python'. Oznacza to, że w powłoce 'python' nie mogę importować pakietów pokazanych przez' pip freeze'. Być może, jeśli najpierw to rozwiążę (tak jak powinienem), może Magic zacznie działać również. – janos

Odpowiedz

2

To jest zalogowany jako błąd w systemie śledzenia błędów JetBrains, , więc mam nadzieję, że wkrótce zostanie rozwiązany.

https://youtrack.jetbrains.com/issue/PY-18074

Możliwym rozwiązaniem jest spaść z powrotem do poprzedniej wersji pycharm:

https://confluence.jetbrains.com/display/PYH/Previous+PyCharm+Releases

Począwszy od 6 stycznia 2016, virtualenv działa dobrze dla mnie w pycharm 4.5.4. Niektóre z virtualenv wcześniej zarejestrowanych za pomocą PyCharm 5.0.3 wydają się nieprawidłowe, ale to w porządku. W rzeczywistości usunąłem wszystkich zarejestrowanych tłumaczy i ponownie dodałem tylko potrzebne mi virtualenv.

Dziwną rzeczą w tej starszej wersji jest to, że czasami PyCharm pokazuje niepoprawną wersję Pythona (2.7 zamiast 3.5), ale pokazuje poprawną listę modułów zgodnie z virtualenv, a edytor nie pokazuje błędów kompilacji, więc miksowanie wersji Pythona nie wydaje się powodować problemów (trochę przerażające).

+0

Dzięki za link do trackera. Zgłaszam ten sam problem, python zainstalowany na Macportach. W rzeczywistości obejściem dla mnie było zainstalowanie i wybranie python2.7. Z 2.7 działa zgodnie z oczekiwaniami, więc jest to wyraźnie problem 3.x (wypróbowany z 3.3 i 3.5) –

Powiązane problemy