I'm trying to bazel build a target inside a virtualenv, and I'm coming across the following error:
Use --sandbox_debug to see verbose messages from the sandbox
Error occurred while attempting to use the default Python toolchain (#rules_python//python:autodetecting_toolchain).
According to '/home/vagrant/venv/bin/python -V', version is 'Python 3.7.5', but we need version 2. PATH is:
/home/vagrant/venv/bin:/home/vagrant/.local/bin:/home/vagrant/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/vagrant/bin
Please ensure an interpreter with version 2 is available on this platform as 'python2' or 'python', or else register an appropriate Python toolchain as per the documentation for py_runtime_pair (https://github.com/bazelbuild/rules_python/blob/master/docs/python.md#py_runtime_pair).
Note that prior to Bazel 0.27, there was no check to ensure that the interpreter's version matched the version declared by the target (#4815). If your build worked prior to Bazel 0.27, and you're sure your targets do not require Python 2, you can opt out of this version check by using the non-strict autodetecting toolchain instead of the standard autodetecting toolchain. This can be done by passing the flag `--extra_toolchains=#rules_python//python:autodetecting_toolchain_nonstrict` on the command line or adding it to your bazelrc.
I tried the --extra_toolchains=#rules_python//python:autodetecting_toolchain_nonstrict flag, but the build still failed after, so I thought I'd try building with python2 involved.
Current state of my system:
Inside virtualenv:
python and python3 seems to resolve to version 3.7.5
python2 doesn't resolve to anything
python2.7 resolves to python 2.7.17
Outside virtualenv:
python resolves to 2.7.17
python3 resolves to 3.7.5
python2 doesn't resolve to anything
python2.7 resolves to python 2.7.17
I want either python or python2 in my virtualenv to resolve to 2.7.17 as well. (I think maybe python2 is safer? I worry changing python can have a lot of other side-effects). For changing python I tried the "sudo update-alternatives" command several times, but it seems to already be pointing to the right thing. It seems like virtualenv just isn't picking it up. Any help would be much appreciated.
Thanks!
Related
Problem having two versions of python on my Mac and them interacting. I have the following python locations
python is /anaconda3/envs/fenicsproject/bin/python
python is /usr/bin/python
and when I try to run a script. I get the following error:
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
I have googled some solutions and have found some posts saying I should try
env PYTHON_CONFIGURE_OPTS="--enable-framework" #or
env PYTHON_CONFIGURE_OPTS="--enable-shared"
This is they type of code I try to run
#Import packages
import dolfin as dl
I installed the env fenics by following the directions here
The google search possibly found Homebrew + Python on mac os x 10.8: Fatal Python error: PyThreadState_Get: no current thread importing mapnik however I was unable to find the library that links to a wrong version of python using otool.
I also found https://github.com/enthought/mayavi/issues/552 which suggests pinning to a different version of python.
Based on the install notes for hippy, https://hippylib.readthedocs.io/en/latest/installation.html then where they say conda create -n fenicproject ... you need to substitute the following:
conda create -n fenicsproject python==3.5.1
conda install -n fenicsproject -c conda-forge fenics==2017.2.0 \
mpi4py matplotlib scipy sympy==1.1.1 jupyter
After this, python -c 'import dolfin' no longer fails. It might also be possible to use a later version of python (I only tried 3.5.1).
What OS are you using? That will largely determine the specifics of how to go about correcting this issue, but the key here is which Python version the system path points to and what Python version your IDE is pointing to.
What you largely want to avoid is a situation where you are running Python scripts via your native system Python (2, likely).
Check which version of Python your IDE is using (from: How do I check what version of Python is running my script?):
import sys
print(sys.version)
Is the first number a 2? Did you want to use Python 2?
Next, let's check what version your system currently defaults to. If Ubuntu/Linux, use:
python -V
Is this expected? If not, you may need to change your system environmental variables to point to the correct Python version. The solution to this is OS dependent. If Windows, search "Edit Environmental Variables for Your Account" -> "Environmental Variables" -> "Path" , be sure it either points to Anaconda or the correct Python version; if Ubuntu/Linux, check your .bashrc file:
gedit ~/.bashrc
to see if the system points to the correct Python variable. If using a Mac, I formally apologize.
Problem:
I'd like to install Pmw 2.0.0 (project page here) so that I can use it with tkinter in python3. The setup script from the package detects which version of python you're using and installs the version that is appropriate for your system (Ubuntu 15 in my case). I can't find any references to switches to make it install the 2.0.0 instead of 1.3.3(the Python 2.7 version), nor have I been able to get the script to install to the python3 libraries.
What I've done so far:
I've changed the python version detector in the setup script from
if sys.version_info[0]<3:
version='2.0.0' # really '1.3.3'
packages=['Pmw', 'Pmw.Pmw_1_3_3', 'Pmw.Pmw_1_3_3.lib',]
to
if sys.version_info[0]<2:
version='2.0.0' # really '1.3.3'
packages=['Pmw', 'Pmw.Pmw_1_3_3', 'Pmw.Pmw_1_3_3.lib',]
to attempt to force the installer to default to the python3 version, which it does, but it installs them in the python2.7 libraries (/usr/local/lib/python2.7/distpackages).
What I want to do:
I'm looking for a way to force the installer to put the 3.4-compatible package into the python3 libraries. If that means getting it to install both packages in their respective correct directories, that's fine, too. I'm stumped about what to try next.
Answered by RazZiel on AskUbuntu:
Link here.
Instead of using the command sudo python setup.py build and then sudo python setup.py install, I should have been using python3 to execute the setup script. I've managed to outthink myself pretty badly on this one.
I am trying to install python through cygwin on a windows machine in order to make use of a statistical program that can only be implemented using python in a linux environment.
I have run setup-x86_64.exe and installed all python related cygwin packages in an attempt to install python, but when I open a terminal and type python I just get
$ python
-bash: python: command not found
which is the same for all python commands I try so clearly the installation has not occurred. However, I have found a path to Python-2.7.9 which appears to contain the files required to build python from source.
When I run ./configure it is successful, but when I then input make it fails due to:
File "build/temp.cygwin-1.7.35-x86_64-2.7/libffi/fficonfig.py", line 33, in <module>
ffi_sources += ffi_platforms['X86_WIN64']
KeyError: 'X86_WIN64'
Makefile:488: recipe for target 'sharedmods' failed
make: *** [sharedmods] Error 1
Anyone know why make won't work?
The options in ./configure --help are unfamiliar to me, could any of these options allow for successful installation?
Any ideas would be greatly appreciated, thank you.
Cygwin comes with an installer, called setup.exe or setup-x86_64.exe. Just run it and type python to the search box. Then let it install it for you.
python language interpreter is the basic package you need.
So, this question is 3 years old, but this error still happens with most recent versions of Python 2 (tested with 2.7.13 and 2.7.15)
I was able to get python to build by modifying the following file in the build directory.
--- build/temp.cygwin-2.11.1-x86_64-2.7/libffi/fficonfig.py~ 2018-11-03 14:51:53.290000000 -0400
+++ build/temp.cygwin-2.11.1-x86_64-2.7/libffi/fficonfig.py 2018-11-03 14:53:41.793000000 -0400
## -9,6 +9,7 ##
'X86': ['src/x86/ffi.c', 'src/x86/sysv.S', 'src/x86/win32.S'],
'X86_FREEBSD': ['src/x86/ffi.c', 'src/x86/freebsd.S'],
'X86_WIN32': ['src/x86/ffi.c', 'src/x86/win32.S'],
+ 'X86_WIN64': ['src/x86/ffi.c', 'src/x86/win64.S'],
'SPARC': ['src/sparc/ffi.c', 'src/sparc/v8.S', 'src/sparc/v9.S'],
'ALPHA': ['src/alpha/ffi.c', 'src/alpha/osf.S'],
'IA64': ['src/ia64/ffi.c', 'src/ia64/unix.S'],
The source files, in particular src/x86/win64.S, are present in the source tree. For some reason, ./configure does not seem to be properly adding the option to the dictionary in the fficonfig.py file, which causes the KeyError posted in the question. After making this modification, make and make install completed successfully and I was able to install an alternate version of python in addition to the normal Cygwin package.
I'm not yet sure why this happens, but I thought I would attempt to provide a solution to the question actually asked rather than just telling the asker to install a pre-compiled version using the package manager.
Since building Python from source was said to be a bad idea, I assumed my Cygwin was broken. I attempted to uninstall Cygwin following the instructions on the Cygwin website, but I was unable to remove it due to permission difficulties (I use a university-supplied Windows machine). My last resort was to run the Cygwin installation wizard setup-x86_64.exe and uninstall all packages, then run the wizard once more and select the necessary packages again as if starting from new. Miraculously, installing the required packages from scratch solved the problem and I am now running Python through my Cygwin terminal with no errors.
If you want to run Python on Cygwin, you might need to build it from source.
download the source
unpack it to the directory you could delete later, eg: build
run Cygwin, type: cd /path/to/build
run ./configure --help and read the help about the options you'll need
./configure #options
make
I am trying to compile pydb for python 3.3, but I have limited access right on my environment.
To avoid accessing forbidden areas, I used the following configure command:
./configure --prefix=/my/prefix
--with-python=/my/python/path/python3.3
--with-site-packages=/my/site/package/path/mysite-packages
But configure complains about the version of python:
checking whether /sw/freetools/python/3.3.0/Linux/rh5/x86_64/bin/python version >= 2.4.0... configure: error: too old
I didn't have the issue when compiling for python 2.7.2.
Could someone help me to solve this installation issue?
Thank you!
I managed to compile (in cygwin) like this:
PYTHON=python3 ./configure --with-site-packages=/usr/lib/python3.6/site-packages
I am having serious issues trying to download the "therubyracer" gem. I think the problem is that I do not have a working libv8 library to create the gem.
I think I do not have a working libv8 because my RubyGems keeps trying to use "Python 2.5.6", which is too old to gem install libv8. I tried countless ways to update the Python that RubyGems uses, however, I cannot figure it out.
Here is what I have done thus far. I went to http://www.python.org/download/releases/3.3.2/ and downloaded "(Mac OS X 64-bit/32-bit Installer (3.3.2) for Mac OS X 10.6 and later 2.)".
Upon completion of the download, I ran:
gem install libv8 --version 3.11.8.17
Yet, I still received the same error. I noticed the output still said:
"Using Python 2.5.4"
Despite downloading a newer Python version, it is not being used. So how do I change the version of Python that the "gem" command uses? I searched and discovered "virtualenv," which appears to be a good Python manager, however I am a bit at a dead end now. Any help or suggestion?
If libv8 uses the python command from the command line, this should apply:
If you do not care what python2 is installed, you can do this in the command line:
type python # this gives you the path of the python command
python is /usr/bin/python
type python2.7
python is /usr/bin/python2.7
Then you can copy one over the other
cp /usr/bin/python2.7 /usr/bin/python
You can safely copy python2.7 there because it is compatible with older versions.
Suggestions?