I installed Python 3.4.2 and Virtualenv 12.0.5 in my Linux Mint 17.1
Then I tried creating:
$ virtualenv venv
And also using --clear and/or -p /usr/bin/python3.4, always getting the messages:
Using base prefix '/usr'
New python executable in venv/bin/python3
Also creating executable in venv/bin/python
ERROR: The executable venv/bin/python3 could not be run: [Errno 13] Permission denied
Another try was:
$ pyvenv-3.4 venv
It gave no errors on creation, but in the venv/bin file the python3.4 is a symbolic link to /usr/local/bin/python3.4. Then when I activate and install any lib using pip or pip3, then try to import it, I get the error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named 'anymoduledownloaded'
I always used virtualenv in Python 2.X and never got this kind of errors. Any thoughts on what am I doing wrong?
Thanks!!
=======EDITED=======
This is the output of my partitions (fdisk -l):
Device Boot Start End Blocks Id System
/dev/sda1 2048 98707455 49352704 83 Linux
/dev/sda2 303507456 3890644991 1793568768 5 Extended
/dev/sda3 * 98707456 303507455 102400000 7 HPFS/NTFS/exFAT
/dev/sda4 3890644992 3907028991 8192000 82 Linux swap / Solaris
/dev/sda5 303509504 3890644991 1793567744 7 HPFS/NTFS/exFAT`
And also my fstab:
<file system> <mount point> <type> <options> <dump> <pass>
-> was on /dev/sda1 during installation
UUID=a38f9c6d-3cd9-4486-b896-acbc6182ec61 / ext4 errors=remount-ro 0 1
-> swap was on /dev/sda4 during installation
UUID=efad7b53-79a8-4230-8226-9ca90c68ea9d none swap sw 0 0`
Is that a shared partition that you have mounted? Does the shared partition have a different filesystem then the non-shared one you tried upon? If yes, then IMO, that will definitely cause an error since you are making and compiling binaries for python on one filesystem, and so it will not work on another filesystem.
As mentioned in this answer, adding to your /etc/fstab with an entry with exec flag might make it work for you, i.e., you might need to add another entry for the NTFS disk here to make it automount:
<file system> <mount point> <type> <options> <dump> <pass>
-> was on /dev/sdaX during installation
UUID=<uid_of_NTFS> / ntfs auto,user,exec,nodev,rw,errors=remount-ro 0 1
I struggled with this as well so I wrote an ugly bash script to help me with this. The only salient difference between what you do and what I do is on line 133:
/path/to/python/bin/python3.4 /path/to/python/bin/pyvenv /path/to/venv
That is, explicitly name the instance of python and the venv tool. Then
/path/to/venv/bin/pip install django # or whatever
Edit
I installed Linux Mint in a VM to try and build a Python 3.4 virtual environment. Based on the error messages I saw and this answer, I learned that I must do the following to get a complete Python 3.4 build:
apt-get install build-essential libssl-dev openssl
Without this, my Python 3.4 build did not contain pip. Note that you probably want to install readline and other development packages.
Unsolicited Advice
Do not do this as root, create a user dedicated to running your venv
Create a script to create your environment
Check that script into your source code repo
I deleted my python binaries and venvs multiple times and then recreated all of with this script to make sure that my script reproduced my environment and then stripped the identifying information and saved that on github to share it. I should really be using a more formal tool for this like docker/puppet/chef.
Related
I updated to MacOS Monterey and now python is not working:
➜ ~ python3 --version
dyld[6578]: dyld cache '/System/Library/dyld/dyld_shared_cache_x86_64h' not loaded: syscall to map cache into shared region failed
dyld[6578]: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: tried: '/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation' (no such file), '/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation' (no such file)
[1] 6578 abort python3 --version
But if I run:
➜ ~ /usr/bin/python3 --version
Python 3.8.9
I am able to run it. But when running code . for opening a project in vs code it gives the same error:
dyld[6683]: dyld cache '/System/Library/dyld/dyld_shared_cache_x86_64h' not loaded: syscall to map cache into shared region failed
dyld[6683]: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
Referenced from: /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Reason: tried: '/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation' (no such file), '/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation' (no such file)
/usr/local/bin/code: line 10: ./MacOS/Electron: No such file or directory
I am not sure what to do so that it runs commands like code . successfully.
This is 100% a version conflict/PATH problem.
First, open up terminal and try running echo $PATH. It should print something like this:
/opt/homebrew/bin:/opt/homebrew/sbin:/Library/Frameworks/Python.framework/Versions/3.10/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin
As you can see, it says 3.10 for me, while yours says 3.6
#guest_fish makes a good suggestion with deleting outdated versions of Python, but another way you can try is by checking the following:
vim $HOME/.zprofile ---> this is the zsh analogue to .bash_profile, here's what mine looks like:
# Setting PATH for Python 3.10
# The original version is saved in .zprofile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.10/bin:${PATH}"
export PATH
eval "$(/opt/homebrew/bin/brew shellenv)"
Note how it matches the first part of the path I echo'd above
vim /etc/paths ---> this should match the middle parts of your PATH, mine looks like this:
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
vim /etc/paths.d/<your_unique_id> (just press tab to complete it when you're in paths.d, you generally have only one option). Mine looks like this:
/Library/Apple/usr/bin
Note how it matches the end of the path
When you visit each of these files, you can modify them (password protected obv) to put /usr/bin/python3 first, meaning that will be the first place that it looks for python build files and will (hopefully) use the correct version
Now, to fix the code thing, you could try going into VSCode and hitting SHIFT + ⌘ + P, then select Shell Command: Install 'code' command in PATH - this should update it for you automatically.
Lmk how it goes!
Your python3 is 3.8.9 but the error message is for 3.6. It looks like you have clashing python versions. I fixed this error on my machine by uninstalling 3.6 and all of its syslinks like seen here under "Uninstalling Python 3 Using Terminal", except I used homebrew commands brew doctor and then brew cleanup for steps 4. and 5.
When I start VIM after activating an Python virtulenv, Python plugins can't find their modules, because they are installed in the system, not in the project's virtualenv.
I am using the aw-watcher-vim plugin, which uses a Python library.
When I create a virtualenv and activate it:
virtualenv -p python3 my_env
. my_env/bin/activate
VIM can't find the module at /usr/local/lib/python3.6/dist-packages/aw_core/ anylonger and prints the following errors:
['Traceback (most recent call last):',
' File "~/.dot-file-repo/neovim/plugged/aw-watcher-vim/plugin/vimwatcher.py", line 6 , in <module>',
' from aw_core.log import setup_logging',
'ModuleNotFoundError: No module named ''aw_core''',
'']
(Slightly reformated for readablity.)
It would be nice to use autocompletion using the code from the virtualenv (via Jedi or so), but let the other plugins find their Python modules. Is there a good solution to this use case?
While some comments suggest to import globally instaled pacckages to virtualenv, I'd suggest to set options in /vimrc to use the system python:
set pythondll=/usr/bin/python
set pythonthreedll=/usr/bin/python3
or whatever your system python is.
The advantage is that you virtual envs are untouched and are used according to your needs.
Since updating from Homebrew Python 2.7.11 (from 2.7.10) I'm suddenly unable to test register my package on PyPi from the PyCharm IDE console.
Running (as an "External Tool")
python -B setup.py register -r pypitest
I now get
Traceback (most recent call last):
File "setup.py", line 22, in <module>
from setuptools import setup
File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line 12, in <module>
from setuptools.extension import Extension
File "/usr/local/lib/python2.7/site-packages/setuptools/extension.py", line 8, in <module>
from .dist import _get_unpatched
File "/usr/local/lib/python2.7/site-packages/setuptools/dist.py", line 16, in <module>
from setuptools.depends import Require
File "/usr/local/lib/python2.7/site-packages/setuptools/depends.py", line 6, in <module>
from setuptools import compat
File "/usr/local/lib/python2.7/site-packages/setuptools/compat.py", line 17, in <module>
import httplib
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 80, in <module>
import mimetools
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 6, in <module>
import tempfile
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 32, in <module>
import io as _io
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
import _io
ImportError: dlopen(/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
Referenced from: /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Expected in: flat namespace
in /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Process finished with exit code 1
I'm not sure how to proceed. I only get this issue if I execute from within my IDE's console. If I do it directly at the system command line (Terminal on OS X) I have no problems.
OS X 10.11.3; Homebrew Python 2.7.11; PyCharm 5.0.3
tl;dr: Fix this issue by doing one of the following:
type hash -r python, OR
log out and log in.
EDIT: An answer to my related question makes it clear what's happening here. When you install a new version of python, you may need to run hash -r python to tell bash to reset the "cached" location to the python executable.
In my case, I was typing python, which was on my $PATH at /usr/local/bin/python. But bash was still using the old cache location /usr/bin/python. So, the old executable was called, but the new path was provided to python in sys.argv[0]. This means that the old executable was running, but the new sys.executable value caused all the wrong modules to get loaded (including the io module).
I'm having the same problem. I installed python 2.7.11 via an installer from Python.org. Strangely, the issue seems to be related to some subtle difference between how OSX launches python when I invoke it from the shell using the full path vs. using just the word python.
So, for me, this works (invoking python via the full path /usr/local/bin/python):
$ which python
/usr/local/bin/python
$ /usr/local/bin/python -c "import io"
$
... but this doesn't:
$ python -c "import io"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Expected in: flat namespace
in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
So, as a workaround, you can try doing the same thing.
Elsewhere, I've posted a separate question about this puzzling behavior. Maybe somehow merely calling python invokes some strange mix of the 2.7.11 executable with the 2.7.10 dylibs??
According to https://github.com/klen/python-mode/issues/634:
I had the same issue, but successfully fixed. In my case I compiled
python and vim with homebrew, when PYTHON_PATH has been specified and
set to one of my dev environments, where I also had some libraries,
including io. Workaround was simple: open new terminal, make sure that
you do not have custom PYTHON_PATH, uninstall python, uninstall vim.
Reinstall both of them.
and
Problem solved.
Culprit is the update from python 2.7.10 to 2.7.11.
If you are using conda package control, simply run "conda install
python=2.7.10" will solve this problem.
This doesn't give the root cause though. Since this happens with _io, this looks like a bug in python 2.7.11 (unlikely, there would be a world-scale outcry and a prompt fix if it was) or some packaging bug or version mismatch specifically with the homebrew version (and maybe some related ones, too).
Try to import _io in the console and if it succeeds, check if it was loaded from the same path.
Reinstall python.
brew unlink python && brew reinstall python
Secure the path
export PYTHONPATH=$PYTHONPATH:/usr/local/bin/
BACKUP and Change the order of "paths" file.
sudo nano /etc/paths
it seems, the order of paths, it is decisive to run python properly. In my case, the result was:
#sudo nano /etc/paths
/usr/bin
/usr/local/bin
/bin
/usr/sbin
/sbin
On my mac, path is like this.
$ which python
/usr/local/bin/python
Now I can run both:
$ /usr/local/bin/python -c "import io"
$ python -c "import io"
I had the same issue, it is successfully fixed by just replacing the _io.so file.
sudo find / -name _io.so
copy the path of the _io.so file which DOES NOT belong to python-2.7.11. For example, copy the path of _io.so which is under python-2.7.5:
/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Replace the /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so file with the _io.so that you just found.
This happened to me as well in MacVim. I solved it by making sure :python print(sys.path) is using system Python (e.g. /Library/Python/2.7/...)
Since I installed MacVim via Homebrew, I just did that by:
Spawn a new shell that had which python -> /usr/bin/python. For my case I needed to remove the pyenv line from my .bash_profile. If you installed Python via Homebrew you may want to brew unlink python first
brew reinstall macvim
If your problem is caused by anaconda, it is unnecessary to remove //anaconda directory.
Just open your ~/.bash_profile, find the line
export PATH="//anaconda/bin:$PATH
and comment it out, then restart your terminal session.
Another quick workaround if you don't mind sticking with Python 2.7.10 is to specify the path of the Python interpreter executable that will be used for the virtualenv. On OSX that path is usually /usr/bin/python:
virtualenv venv --python=/usr/bin/python
Can't add comment (?) so this just to share my exp., downgrade to 2.7.10 works fr me.
I got this error after a failed NLTK download, I needed to uninstall anaconda:
sudo rm -rf ~/anaconda
update PATH variable
This happened when I already had tried to create a venv in a folder, and mistakenly was trying to initialize a second one! So I just removed venv directory and re-ran the command. Very likely this is not the answer to this solution, but searching my error brought me here, so it may help some others who are stuck.
I solved this issue by removing the symbolic link that was in /usr/local/bin and copying the actual python binary, that was pointed to by said link, there.
I had the same issue when I tried to use PyCharm. Solved by setting "python interpreter" in project configuration to point to the python virtual env I wanted to use, which was an Anaconda env. Somehow the interpreter path was missing the "anaconda" portion of ~/.../anaconda/.../_io.so. No need to uninstall anaconda.
I am trying to install pdfMiner to work with CollectiveAccess. My host (pair.com) has given me the following information to help in this quest:
When compiling, it will likely be necessary to instruct the
installation to use your account space above, and not try to install
into the operating system directories. Typically, using "--
home=/usr/home/username/pdfminer" at the end of the install command
should allow for that.
I followed this instruction when trying to install.
The result was:
running install
running build
running build_py
running build_scripts
running install_lib
running install_scripts
changing mode of /usr/home/username/pdfminer/bin/latin2ascii.py to 755
changing mode of /usr/home/username/pdfminer/bin/pdf2txt.py to 755
changing mode of /usr/home/username/pdfminer/bin/dumppdf.py to 755
running install_egg_info
Removing /usr/home/username/pdfminer/lib/python/pdfminer-20140328.egg-info
Writing /usr/home/username/pdfminer/lib/python/pdfminer-20140328.egg-info
I don't see anything wrong with that (I'm very new to python), but when I try to run the sample command $ pdf2txt.py samples/simple1.pdf I get this error:
Traceback (most recent call last): File "pdf2txt.py", line 3, in <module>
from pdfminer.pdfdocument import PDFDocument ImportError: No module named pdfminer.pdfdocument
I'm running python 2.7.3. I can't install from root (shared hosting). The most recent version of pdfminer, which is 2014/03/28.
I've seen some posts on similar issues ("no module named. . . " but nothing exactly the same. The proposed solutions either don't help (such as installing with sudo - not an option; specifying the path for python (which doesn't seem to be the issue), etc.).
Or is this a question for my host? (i.e., something amiss or different about their setup)
I had an error like this:
No module named 'pdfminer.pdfinterp'; 'pdfminer' is not a package
My problem was that I had named my script pdfminer.py which for the reasons that I don't know, Python took it for the original pdfminer package files and tried to compiled it.
I renamed my script to something else, deleted all the *.pyc file and __pycache__ directory and my problem was solved.
use this command worked for me and removed the error
pip install pdfminer.six
Since the package pdfminer is installed to a non-standard/non-default location, Python won't be be able to find it. In order to use it, you will need to add it to your 'pythonpath'. Three ways:
At run time, put this in your script pdf2txt.py:
import sys
# if there are no conflicting packages in the default Python Libs =>
sys.path.append("/usr/home/username/pdfminer")
or
import sys
# to always use your package lib before the system's =>
sys.path.insert(1, "/usr/home/username/pdfminer")
Note: The install path specified with --home is used as the Lib for all packages which you might want to install, not just this one. You should delete that folder and re-install with --
home=/usr/home/username/myPyLibs (or any generic name) so that when you install other packages with that install path, you would only need the one path to add to your local Lib to be able to import them:
import sys
sys.path.insert(1, "/usr/home/username/myPyLibs")
Add it to PYTHONPATH before executing your script:
export PYTHONPATH="${PYTHONPATH}:/usr/home/username/myPyLibs"
And then put that in your ~/.bashrc file (/usr/home/username/.bashrc) or .profile as applicable. This may not work for programs which are not executed from the console.
Create a VirtualEnv and install the packages you need to that.
I have a virtual environment and I had to activate it before I did a pip3 install to have the venv see it.
source ~/venv/bin/activate
after a computer fix my python projects dir (windows) changed (say from d: to f:).
now all my virtualenvs are broken. after activating the env the project inside the virtualenv can't find the dependencies and the custom scripts (from the env\scripts folder)won't work
tried running:
virtualenv --relocateble ENV_NAME (with the env name ..)
like in this stackoverflow question and it outputted a lot of lines like:
Script agent\Scripts\deactivate.bat cannot be made relative
and my virtualenv is still broken.
when I manually changed activate.bat set VIRTUAL_ENV to the new path. some scripts work again. but the relocate scripts still doesn't run and most of the scripts are still broken
even running the python interpeter fails with:
Traceback (most recent call last):
File "F:\Python27\learn\agent\agent\lib\site.py", line 677, in <module>
main()
File "F:\Python27\learn\agent\agent\lib\site.py", line 666, in main
aliasmbcs()
File "F:\Python27\learn\agent\agent\lib\site.py", line 506, in aliasmbcs
import locale, codecs
File "F:\Python27\learn\agent\agent\lib\locale.py", line 19, in <module>
import functools
ImportError: No module named functools
is there any way to fix this? HELP
Update: I also changed manually the shebang python interpeter line in all scripts in ENV\Scripts. now all fail with the same python failure as above
Another Update: to #udi the system python path is:
['', 'C:\\dev\\Python27\\lib\\site-packages\\distribute-0.6.37-py2.7.egg', 'C:\\
dev\\Python27\\lib\\site-packages\\pip-1.3.1-py2.7.egg', 'C:\\dev\\Python27\\lib
\\site-packages\\numpy-1.7.1-py2.7-win32.egg', 'C:\\dev\\Python27\\lib\\site-pac
kages\\pandas-0.11.0-py2.7-win32.egg', 'C:\\dev\\Python27\\lib\\site-packages\\p
ytz-2013b-py2.7.egg', 'C:\\dev\\Python27\\lib\\site-packages\\python_dateutil-2.
1-py2.7.egg', 'C:\\dev\\Python27\\lib\\site-packages\\six-1.3.0-py2.7.egg', 'C:\
\dev\\Python27\\lib\\site-packages\\tornado-3.0.1-py2.7.egg', 'C:\\dev\\Python27
\\lib\\site-packages\\pyzmq-13.1.0-py2.7-win32.egg', 'C:\\dev\\Python27\\lib\\si
te-packages\\pygments-1.6-py2.7.egg', 'C:\\Windows\\system32\\python27.zip', 'C:
\\dev\\Python27\\DLLs', 'C:\\dev\\Python27\\lib', 'C:\\dev\\Python27\\lib\\plat-
win', 'C:\\dev\\Python27\\lib\\lib-tk', 'C:\\dev\\Python27', 'C:\\dev\\Python27\
\lib\\site-packages', 'C:\\dev\\Python27\\lib\\site-packages\\setuptools-0.6c11-
py2.7.egg-info']
since I can't run python from the virtualenv, I can't print the python path from there
Correcting python directory path in ENV_FOLDER\Lib\orig-prefix.txt helped me
Seems like your system and local environments create a mix of libraries and binaries from different versions of python.
Chances are you would need to delete Lib, Scripts and Include and start again with virtualenv .. You might be able to save the site-packages folder, but if you have requirements.txt files, you should probably reinstall packages instead (see also: How do I install from a local cache with pip? ).
Anyway, I believe you can create a script that does all this in one step.
I installed both py2 and py3 on my windows 10. And got this error by create virtualenv by using virtualenv xxx directly. After purging folder xxx and reinstalling with virtualenv -p TARGET_PY_EXE xxx everything works smoothly.
Hope this will help multiple python windows users.
By the way, I simply create env variables as PY2 and PY3 instead of adding absolute paths into PATH.