PyCharm doesn't list, or install, some packages unless venv was created with virtualenv

I should start with the disclaimer that I am running Snow Leopard on my Mac.

I use various scientific packages [numpy, matplotlib, scipy, sympy]. In the past, I have found I was not able to install some or all of these packages using the Install feature of PyCharm's Project Interpreter Preferences. When such problems occurred, it was a no-go whether PyCharm's PI was a virtual env or not. A workaround I discovered was, since I use a Mac and since I have Mac Ports installed, to install the Mac Ports version of whatever package I wanted to a virtual env created not by using PyCharm's Project Interpreter Preferences but by using the Mac Ports port of virtualenv instead.

My experience is that Mac Ports packages are more compatible with my Mac than the ones that PIP [which PyCharm uses I think] pulls down. It is not that big a deal to create venvs with virtualenv from a term session, and install packages with Mac Ports instead of PyCharms' Install feature, so I can live with the Way things are.

Nevertheless, since Python v3.3 now has a built-in alternative to virtualenv which PyCharm's Project Interpreter uses, I decided to revisit the problem. Alas, not only has nothing changed, but even if I create a venv using python v3.3's pyenv from a term session, and then install Mac Ports numpy and sympy packages, PyCharm still does not see those packages. PyCharm will only see those packages if the venv was created using Mac Ports' py33-virtualenv port.

And, yes, I do use the –system-site-packages switch when creating venvs from a term session.
1
Does it help if you press Reload in the Paths tab of the pyenv-created Python interpreter settings after you install the MacPorts packages?
0
Avatar
Permanently deleted user
Just tried that on a venv I created with PyCharm rather than from a term session using pyenv or virtualenv. But, after Reload completed without any error message, and I switched back to the Packages tab, sympy and numpy were not listed. The weird thing is that if I open a term session, cd into the bin folder of that venv, then enter python, IDLE confirms that Python loaded and I can enter 'import sympy, numpy' and then 'help(sympy.cos)' and those two statements execute as expected.

A disturbing aspect of this is that the Packages tab for the PyCharm created venv lists pip v1.1 as the one being used. Ditto for the pyenv created venv. It is only for the virtualenv created venv that Packages correctly shows the latest pip v1.2.1 as what is being used. Browsing the lib folders for the venvs using Finder confirms that Packages is reading what really was installed. So, maybe, the Mac Ports virtualenv port is smart enough to know, in the wacky world of Apple, to use the Mac Ports installed pip rather than the one from somewhere in the Apple installed framework that PyCharm and pyenv use... which would explain my problems with venvs both pre- and post python v3.3.

Admittedly, Macs are weird in that Apple installs its python framework in one place while Mac Ports installs its ports of Python elsewhere. General consensus is that you should not dork with Apple's frameworks. I have learned from painful experience to use Mac Ports distributed python packages and not the ones from Apple or even from python.org. That is precisely why I use Mac Ports and venvs – so that I do not have to play in Apple's sandbox.

Is there somewhere in PyCharm's preferences where I can specify the location of pip used when creating, and installing packages into, venvs? Specifically, I need PyCharm to use usr/local/bin/pip when creating, and installing packages into, a venv. Attempts to upgrade the version of pip in PyCharm-created venvs, using the Upgrade button in the Packages tab, fail.
0
Avatar
Permanently deleted user
During my efforts to find a more transparent Way to use MacPorts with PyCharm, I discovered something which is related to the topic of this thread. As I said in my previous comment, the PIP that PyCharm insists on using is not the PIP that MacPorts wants to use and that disconnect can lead to problems with venvs unless you create venvs, and install packages for those venvs, from MacPorts instead of PyCharm. Unfortunately, I know of no way to configure PyCharm to use a PIP of your choosing. Even worse, once PIP and DISTRIBUTE have been installed in a PyCharm PI, PyCharm greys out the UNINSTALL button so you are stuck with it.

Recently, I completely uninstalled MacPorts and reinstalled it, which meant I had to reconfigure PyCharm's PIs as well. As it turns out, this time around I created the PyCharm PIs before I installed any Mac Ports other than python27 and its dependencies. That revealed an intriguing anomaly. From there, when I did attempt to install the py27-numpy Mac Port, MacPorts was not able to activate it, reporting that non-MacPort versions of easyinstall amd setupinstall were already installed. easyinstall, setupinstall, pip, and distribute are all somewhat related in how packages are manipulated by venvs and PIs in general, ergo, the aforementioned conflicts.

MacPorts provides a Way to resolve the conflict, which is use the -f switch to force activation. But, among other things, that renames the non-MacPort file to something else. Which makes MacPorts happy but may create problems for other apps.

It seems to me that the best solution for everyone concerned is for all apps which use PIs [such as PyCharm and Eclipse, for instance] to provide the user with a Way to configure the location of the package manipulating files [pip, distribute, easyinstall, setupinstall].

This seems like such an obvious need that I am wondering if it already exists and I am missing it.
0
PyCharm does not provide any possibility to customize the location of pip because so far we haven't seen any environments which would require a non-standard version of pip. You're welcome to file a feature request at http://youtrack.jetbrains.com/ for the support of the MacPorts version of pip.
0
Avatar
Permanently deleted user
Just to make sure I am understanding what you appear to be saying, jetbrains considers MacPorts to be non-standard?
0
The standard version of pip is the one available from http://www.pip-installer.org/
It's also the version that we bundle with PyCharm. If MacPorts makes some changes to pip which are not included in the officially released version, then obviously the result of those changes is a non-standard version of pip.
0
Avatar
Permanently deleted user
Unfortunately, PyCharm's package installer consistently fails to install several 'standard' packages that I require — specifically, scientific computing packages like sympy, scipy, matplotlib, vtk, mayavi, and the most recent version of numpy. To use these, I install 'non-standard' Mac Ports of them, first, and then, afterwards, associate a PyCharm PI with the Mac Port python interpreter or venv.

Admittedly, ipython and/or emacs have become sort of the de facto standards in the scientific community. But, it would be nice if PyCharm integrated more seamlessly with the aforementioned scientific computing packages.
0
Avatar
Permanently deleted user
I discovered a way to get PyCharm to use a MacPorts installed version of pip. This Way does not require a venv:

1) Use MacPorts to port install python27 and any other packages [ergo, py27-whatever] you wish to use with python27.

2) Here is the important step I was not doing before –> use MacPorts to port install py27-pip _before_ you create a PyCharm PI for the MacPorts installed python27.

3) Use PyCharm Preferences to add a Protocol Interpreter associated with the MacPorts installed python27 [that would probably be /opt/local/bin/python2.7 unless you specified elsewhere during installation of MacPorts.]

4) PyCharm figures out that MacPorts has already installed py27-pip and associates that with this particular PI. Hence, PyCharm will list all the MacPorts packages installed in steps 1) and 2) for this particular PI.
0
Avatar
Permanently deleted user

Thank you, Istlota! This helped me get started using MacPorts with PyCharm. This should be in the HOWTOs!

0

请先登录再写评论。