I installed a second older Version of python (3.6) because I couldn't do something in my newer version. I created a new pycharm project with a new virtual environment and 3.6 as base interpreter. But when I try to install a package in pycharm (for example numpy) I get the error: no such option: --build-dir
Some things of note, that might be important to answer my question: I haven't added 3.6 to the path, when I installed it because the newer version is the one I mainly use. Also according to the following code my pip version is 21.3.1 :
import pkg_resources
print(pkg_resources.get_distribution("pip").version)
Related
I'm creating virtual environment with virtualenv library.I want to decrypt the .pyc extension file.The purpose of me using this library is that Uncompyle6 library doesn't support python 3.9 it yet.
I installed the 3.8.0 version of python in the virtual environment.Then i installed Uncompyle6 library.
Up to this point there was no problem.When I checked the python version in terminal, it showed 3.8.0
uncompyle6 file.pyc > file.py
When I run this code I get the following error.
RuntimeError: Version 3.9 is not supported.
My questions is:
Why doesn't it reference my version of python in the virtual environment? and
How can I run it with the python version I installed in the virtual environment?
Idea is to build the distroless docker image and available python3 google distorless image version is 3.7 - gcr.io/distroless/python3. Our code is already compiled and running with python3.5 version and required to upgrade the version into 3.7 so that we can get rid of the library, compactability issues and can make use of the distroless image with verison 3.7. Some questions are,
Will version upgrade cause any issues to the existing code compilation?
Do we need to change all the requirements.txt versions according to the 3.7?
If yes, will there is an impact of the application?
the Python language does not provide backward compatibility. My recommendation for you is to run your code on a virtual env with the new version of Python and test your code. If you do not want to use virtual env you could create a new docker image with the Python version and test your app. Regarding the requirements.txt, without seeing the libraries or packages there, it is impossible to say if you should change the file.
I have just installed pycharm 2019 edition. I have already installed python 3.7 in my system. My normal python program in pycharm is running fine i.e. printing hello world but I am not able to install packages like pandas and all. its showing error. 2nd thing i am not able to see latest version of pip that is been shown in pycharm.
I have tried to do this with some changes in manage repositories but It didn't wokred
While clicking on pip its showing "Error loading package list:pypi.python.org" this error message.
I want to install packages but cant able to do it.
Please download Anaconda Distribution, which is basically made for pandas and all. You can use Spyder which is one of the best tools for Data Science. There you can easily install pandas.
I have the following issue: I have installed anaconda 3 and installed a package called "pygrib" into my anaconda environment. Now when importing pygrib in a file in my environment, it will show me this error:
import pygrib
ImportError: libhdf5.so.10: cannot open shared object file: No such file or directory
As I am a noobie, I dont really know what to do with this information. I installed the h5py package and some other related ones, but it didnt resolve the issue. What to do?
This is a linking error with the HDF5 library. Are you building pygrib from source or using the conda-forge channel to install it via conda? When I use the conda-forge build of pygrib I get the same issue. The GRIB API from ECMWF (on conda-forge it is listed as ecmwf_grib) is what pygrib depends on and the HDF5 dependency comes from netCDF4 being used in the GRIB API library. Specifically, using the latest HDF5 (1.10.0 at this time) is what is causing a problem. Using HDF5 1.8.* instead allows pygrib to import properly.
To force conda to grab a specific version, just do:
conda install pygrib hdf5=1.8
This will get conda to solve the package specifications again with the older HDF5 library and likely clear up the issue. This assumes you are in the conda environment that you installed pygrib into. You could also create a new environment with conda create -n <env name> pygrib hdf5=1.8 if you wanted to.
In general, when you see these errors where a library is not found, it is often a matter of getting the right version of a library installed. With conda, this sort of thing happens when updating packages and a newer version of a library gets installed that a package you are using has not been properly linked with. As long as you can track down the package/library that is causing trouble, you can use the above procedure to start requiring certain versions of things get installed and conda should then update or downgrade things so that things work together again. Hopefully this makes sense and helps.
This part may or may not interest you, but what I cannot say for certain is where this problem originates. My guess is that it is something with ecmwf_grib and how it is built. That is where ldd shows the old HDF5 dependency showing up for my installation. If I can figure out the exact issue, I'll update this answer.
In order to run an optimization problem we set up Gurobi 6.0.4 together with
Anaconda (Version 2.2.0) Python (Python 2.7.9.) on
Linux CentOS release 6.6 (Final) with the 2.6.32-504.16.2.el6.x86_64 Kernel
Following the installation guidelines of Gurobi (listed here: http://www.gurobi.com/documentation/6.0/quickstart_linux.pdf)
everything worked out in the first step. Gurobi was installed, could obtain a license. Also the PATH variables have been set (in the .bashrc) according to the manual, with a little extension for the referal to anaconda python (and not the other local Versions of python (being 2.7 and 3.4):
export GUROBI_HOME="/opt/gurobi604/linux64"
export PATH="${PATH}:${GUROBI_HOME}/bin:${PATH}:opt/anaconda/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"
Following the procedure we executed: python2.7 setup.py install in the respective directory /opt/gurobi604/linux64. After this usually you could run the import gurobipy command in the python interpreter wihtout errors. For older Versions of Gurobi (as 5.6.3) this works out very well.
For 6.0.4 though we constantly receive the error:
ImportError: /opt/anaconda/lib/python2.7/site-packages/gurobipy/gurobipy.so: undefined symbol: _Py_FalseStruct
This is very reproducible, no matter if we put anaconda also in the global path, and check the bash for any overwriting of the environment variables, which is not the case.
On Windows 8 the Gurobi 6.0.4 and Anaconda Python 2.2.0 work together without any problems.
Also applying hints from here: Python Module Error on Linux did not work out.
Did anyone else experience these problems with this tooling combination? thx.
The error message indicates that you use the Python module for version 3.4 in your Python 2.7 package directory. This can happen if you do not clean your Python module build directory between builds. Please try the following:
Completely remove the 2.7 package from your Python 2.7 installation (e.g. remove /opt/anaconda/lib/python2.7/site-packages/gurobipy)
Completely remove the Python module build directory from your Gurobi installation (e.g. /opt/gurobi604/linux64/build)
Re-run the build process for the Python 2.7 module (e.g. run "python2 setup.py install" in /opt/gurobi604/linux64)
Please note that CentOS is currently a non-supported platform for Gurobi.
Thank you for the hint, I think we tried that, but did not finish the procedure in this way. We tried to clean the system but in that particular case still hat both python Versions (due to other applications that use 3.4) on the machine. Our solution in this case was just to reinstall everything clean on a Ubuntu 14.04 VM. Since then no further problems occured. (I know not the cleanest solution.)
We had some similar issues when we updated to Gurobi 6.5, but that could be solved when corrctly addressing the usual path issues.
Thank you in any case for the reply, I think this really will help us with the next, then clean deployment :-)