I cannot import a module that I see in the pip freeze list (in my case django-olwidget, but I don't think it's nothing to do with this module).
With the virtual environment activated, I:
uninstalled an old version of the module (0.47)
confirmed that it is gone from the freeze list
pip installed the module again
checked the module is in the freeze list now (django-olwidget==0.50)
The environment is active but, now I cannot import the module. Any ideas?
I don't know if this question is still relevant, but I had a similar problem which I just asked a question about before realizing the error. See here. TL;DNR need to specify pip version to install packages correctly.
For python 2.7:
pip2.7
Related
This question is somewhat similar to the one here, but I cannot make it work.
So suppose that I have a set of packages (say 2) to install and I want to use pipenv. If I do pipenv install on the directory with a suitable Pipfile the installation fails because there is some metadata issue when installing one of the libraries (say libX) contained in install_requirements of one of the packages. It seems that the problem can be fixed by downgrading the version of setuptools to <=58.0.0.
OK. Now, if I first install that version of setuptools<=58.0.0 in the venv and then install my packages, everything works fine. The issue is that the Pipenvfile does not respect the order when installing, so something like
[packages]
setuptools = "<=58.0.0"
pckg1 = {<github path 1>}
pckg2 = {<github path 2>}
is not ensured to work. Also, by default the seed packages added to the venv include setuptools==65.6.3.
So the idea is to be able to restrict the version of setuptools that is used to check the metadata of the libraries in libX, to mimic the above scenario in which setuptools was installed first. Is there a way to do that?
I have tried placing setuptools<=58.0.0 at the top of the requirements.txt that defines the install_requirements of the problematic package, but it does not work.
If have also tried to fix or restrict the version of libX contained in that requirements.txt file but, surprisingly, pipenvdoes not seem to care: a verbose install shows that it keeps downgrading libX well below the restriction - "using cached libX-vX.X.X"- until it uses a version for which the metadata generation fails (why on earth does it do that, even if I call it with pipenv --clear install?).
I am a bit lost about what could be the best solution here. Any help would be very appreciated.
I have installed WinPython and want to use Spyder. I use pip and virtual environments. I have followed the instructions here modular approach. Everything works just dandy until the very last instruction "Start a new IPython console (in Spyder). All packages installed in your venv environment should be available there.".
It get error Your Python environment or installation doesn't have the spyder‑kernels module or the right version of it installed (>= 1.9.0 and < 1.10.0). Without this module is not possible for Spyder to create a console for you.
But I installed spyder-kernals in my venv, I can literally see them there, I set the path the the python installed in the venv, everything should work, but it doesn't!
Any thoughts?
I asked CAM Gerlach as suggested, and he spotted my error very quickly. The instructions at modular approach are correct except they say pip install spyder-kernels==0.* which I took literally. In fact as per the error message you need to use later versions, so I used pip install spyder-kernels==1.10 and it fixed it.
You may have to ask to "C.A.M. Gerlach" if he has an update on the procedure: Spyder has evolved a bit with Spyder-4.
After upgrading PyCharm to version 4.0.1 and OS X Yosemite to version 10.10.1, I encountered the following problem:
When trying to import basic modules, e.g: import time or import sys, PyCharm marks the import as an "Unresolved reference" (red underline) and does not recognise the module name.
When trying to figure it out, I noticed that while writing the module name the auto completion pop up is finding a match on the 'lib-dynload' folder within my virtualenv path (/Users/myname/Envs/envname/lib/python2.7/lib-dynload) rather than on the 'site-packages' folder.
There are also added to the PYTHOPATH in this order (lib-dynload before site-packages).
As a workaround I removed the lib-dynload path from the "project interpreter" setting window in PyCharm which made PyCharm recognise the basic modules again, but I am not sure what other impacts this change might have.
My Question is whether there is a way to reproduce the original behaviour PyCharm had so it would recognise the basic modules without tampering the paths of the virtualenv used as a project interpreter.
I am using a separate installation of Python (/usr/local/Cellar/python/2.7.6/bin/python) and virtualenv version 1.10.1.
I'm using pycharm 4.0.1 and virtualenv 1.11.6 and everything works fine to me, but i'm on Arch Linux not OSX.
You may try to recreate the virtualenv, and invalidate and restart the pycharm cache, then wait for pycharm to index again your virtualenv.
Don't know if this is too much of a hassle to you, maybe it is worth a try.
This is a django project tree i tried:
This is probably a bug, a recent youtrack issue seems to match your problem.
I just installed Canopy Express 1.4.1 (32-bit) for Windows. Among the packages that are supposed to be there (see https://www.enthought.com/products/canopy/package-index/ ) are pandas and statsmodels. But after installing, neither is listed in Package Manager, either as being installed or available.
The lack of pandas is not a problem, as pip easily installs it. (Enthought notes that packages installed that way will not be listed in Package Manager, but are fully available in the Canopy User Environment. Indeed, it imports.
statsmodels is not so easy. pip only gets source, and there is no Windows installer provided by the statsmodels folks. There is a nightly Windows binary, but not (if I'm reading correctly) for the stable build. The suggested solution by statsmodels is to compile it, using MinGW, which I do not currently have installed.
With enough trouble, I imagine I could compile and install, but is there a way to save all that trouble and get the packages within Canopy, as Enthought says it should be?
Seems like your Package Manager is misbehaving or you are looking in the wrong place (look in Free Packages not Community Packages).
Pandas is indeed in the Express installer, so always installed. At Canopy's python prompt, type:
import pandas
Though sounds like you've already overwritten it with pip, not really a problem but not the cleanest path (mixing 2 different installation methods for the same package).
Statsmodels is listed in package manager (Free package). It is available to free users but is not yet in the Express installer.
If you still don't see these in the pkg mgr, please quit Canopy, ensure that all Canopy processes have terminated (easiest way... log out of Windows, then back in), and restart Canopy.
Running on MAC os 10.6.8
with postgresSQL installed, as well django - using python2.7
Also installed psycopg2 and dj-database-url using pip in my virtual env
And added these two lines to my setting.py:
import dj_database_url
DATABASES = {'default': dj_database_url.config(default='postgres://localhost')}
Based on instructions for Heroku in:
https://devcenter.heroku.com/articles/django#database_settings
When running:
python manage.py runserver
I am getting this error:
ImportError: dlopen(/Users.... venv/lib/python2.7/site-packages/psycopg2/_psycopg.so, 2): Symbol not found: _PQbackendPID
Referenced from: /Users.... venv/lib/python2.7/site-packages/psycopg2/_psycopg.so
Expected in: dynamic lookup
I kept searching for hours and tried all kind of thing including the advice on:
Mac OS X Lion Psycopg2: Symbol not found: _PQbackendPID
to no avail.
Wonder if anyone had such an issue and had any luck.
I had the same problem. Instead of installing the dependencies as Heroku suggests using
pip install Django psycopg2 dj-database-url
clone whatever repo you're hoping to run in venv, keeping its original settings.py. Then:
source venv/bin/activate
to activate the new environment, cd into your new repo, and python manage.py runserver. Should be set.
Alternatively, you could remake PostGreSQL, and run again, but that's a bit more of a task - it would work for psycopg2, though. As far as I can tell that issue comes from using an 64 or i386 build when you should be using a 32 build - but I'm not sure about this, and the above solution works well to solve the problem and use venv for what you're actually going to be using it for, most likely.
I had the same problem as you guys and I had read many pages and I couldn't find the answer in any of them. Many solution was about installing from source file and don't relate to the virtual environment.
I've found and tested following solution and it solve my problem.
1- Make sure your Postgres is NOT higher than 9.4 version according to psycopg2. Check python version as well. I use Postgres 3.9.9.
2- The problem is behind different version of Python(32/64 bit). It should comply with your operation system's bit architecture which is 64bit. Uninstall all versions of Python and pip from your system. Instruction you can find here but do NOT remove Python2.7 which is Apple-supplied system Python.
3- Install "Mac OS X 64-bit/32-bit" installer from python official website and install it.
After that install pip. Note that you should use the command "python3.5" for using Python version 3.5. You might install virtualenv from the new pip as well.
4- After all that you can go on your virtualenv and type "pip3 install -r requirement.txt" for installing all dependencies on your local machine.
Hope this can help you.