Problems with Installing Python Packages - python

I've seen some past threads that discuss similar problems, but none seem to be having exactly the problem that I am having. I was having problems with installing packages with Python, even though I'd managed to install them before. When I attempted to run gcc, it seemed to not be installed, so I uninstalled Xcode completely and just installed the command line tools (I really only use the command line tools, and could use the extra disk space).
Though the installer said that the installation was successful, gcc results in the following error:
xcrun: Error: could not stat active Xcode path '/Applications/Xcode.app/Contents/Developer'. (No such file or directory)
I have tried to redirect the path by using the following command:
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
It doesn't seem to work, though.
I've also tried using the following command:
sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer
but it returns the following error: xcode-select: Error: Path "/Applications/Xcode.app/Contents/Developer" is not a directory.
Which makes sense I think -- after all, I did uninstall Xcode, so I suppose I should point it to the Command Line tools directory? I'm not sure how to do this, though.
I'm using Mac OS X 10.8.5, by the way.

Related

Issues compiling GTK software in MSYS2/MinGW with PyInstaller

I had a year old version of MSYS2/MinGW that was using PyInstaller with Python3.7 to compile a C GTK application in Windows (python was needed for a plotting script) and everything worked fine until pacman refused to update any packages since I kept getting the error:
error: hook /usr/share/libalpm/hooks/mingw-w64-x84_64-gtk-query-immodules-3.0.hook line 2: invalid value Path
error: hook /usr/share/libalpm/hooks/mingw-w64-x84_64-gtk-update-icon-cache.hook line 2: invalid value Path
Errors occurred, no packages were upgraded.
I looked those up and the general response for it is: "The issue is usually provoked when you don't maintain your system at regular intervals - and I am not thinking yearly - because such neglect will often result in similar problems. The issue stems from a change in pacman code..."
So I decided to start from a fresh MSYS2 install and used the following lines from both an MSYS2 shell and a MinGW-x64 shell, and each of them fails at a different point:
pacman -Syu
pacman -Su
pacman -S nano
pacman -S mingw-w64-i686-gtk3
pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-gtk3 mingw-w64-x86_64-python3 mingw-w64-x86_64-python3-gobject
pacman -S --needed base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain git subversion mercurial mingw-w64-i686-cmake mingw-w64-x86_64-cmake
pacman -S python3-pip
pacman -S mingw-w64-x86_64-python3-pip
pacman -S msys2-devel
pacman -S mingw-w64-x86_64-glade
pacman -S mingw-w64-x86_64-gobject-introspection
pip install pyinstaller
In the case of the MSYS2 shell, the pip install pyinstaller fails with:
# pip install pyinstaller
Collecting pyinstaller
Using cached PyInstaller-3.6.tar.gz (3.5 MB)
Installing build dependencies ... done
Getting requirements to build wheel ... error
ERROR: Command errored out with exit status 1:
command: /usr/bin/python3.exe /usr/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmpd9hk1ekp
cwd: /tmp/pip-install-ouq11vnr/pyinstaller
Complete output (1 lines):
Your platform is not yet supported. Please define constant PYDYLIB_NAMES for your platform.
An internet search shows this issue coming up on the github page for PyInstaller and a post here, neither of which were remotely enlightening:
https://github.com/pyinstaller/pyinstaller/issues/4542
How to fix: PyInstaller in MSYS2 MinGW 'Your platform is not yet supported'
In the case of a MinGW shell, I can install everything fine, but I cannot compile the C code because I get the error:
fatal error: sys/wait.h: No such file or directory
7 | #include <sys/wait.h>
| ^~~~~~~~~~~~
compilation terminated.
Which means that MinGW doesn't know where to look for this file. It is located in:
msys64/usr/include/sys
but I suppose that only works for an MSYS2 shell? And yet my year old MinGW shell will compile the C code without this error, but despite every effort (following the bash history for package installation for the working version, manually copying over package folders, on and on) I continue to come up against this error. Just copying the folder above into the MinGW include folder results in further issues and is clearly sloppy. I want a repeatable way to get this to work, and I have repeated the process outlined above on several computers and have got the exact same result every time - so I expect anyone starting with a fresh MSYS2 install will run up against the same problems. Any help in getting this to run would be very much appreciated as I am getting frustrated with all of the dead ends.
I was finally able to get this figured out. The first thing to know is that the initial compiling must be done in the MSYS2 shell. Once you successfully compile it in the MSYS2 shell, you can then compile in the MINGW shell without issue. I am not sure why that is so, but I anticipated it would be the case.
I solved the PyInstaller issue by downloading Python 3.7 from http://repo.msys2.org/ and installing it using:
pacman -U python-3.7.2-1-x86_64.pkg.tar
I also needed Python 3.7 installed in Windows, and the path edited in my .bashrc file:
export PYTHON_HOME=C:\\Users\\Leigh\\AppData\\Local\\Programs\\Python\\Python37
export PATH="$PYTHON_HOME:$PYTHON_HOME\\Scripts:$PATH"
I am not sure if PyInstaller is compatible with Python 3.8 yet. I posted an issue to their GitHub page, and it is here for reference in case it is resolved:
https://github.com/pyinstaller/pyinstaller/issues/4996
PyInstaller then worked, but I was met with another issue that I posted to Stack Overflow, but figured out as well. That is here:
MSYS2 gcc fatal error in cc1.exe: cygheap base mismatch detected
After that issue was resolved I could compile my program in MSYS2. Switching over to a MINGW shell, I found that it now compiled there as well.
sys/wait.h isn't there in MinGW, but you can use the one from: https://github.com/win32ports/sys_wait_h

Pip install --global-option="-L/<library path>": option -L not recongnised

I am trying to install cartopy on a Windows machine, and have previously installed QGIS and GEOS through OSGeo4W64. Now, when I try installing cartopy, I get the following error:
fatal error: 'geos_c.h' file not found
As mentioned, GEOS does exist and the file is also to be found within the directory. I the tried giving Pip the absolute path to the library as a global option, as follows:
pip install --global-option="-Lc:\OSGeo4W64\include"
This, unfortunately didn't work because Pip didn't recognise the -L library option:
error: option -L not recognized.
I tried -I, -l, and -i as well, just to see what would happen, but I get the same error every time. I also found examples on how to give paths to global-option and they did use -L and -I without problems. What could I be doing wrong?
Any help would be greatly appreciated.
It depends where you get your GEOS from as to which GEOS header file you should be linking against. If you get it from Christoph Gohlke's excellent binaries, or conda-forge, enthought, or Anaconda, I believe all rename geos_c.h to geos.h. If you get it from other sources, it may be that that renaming doesn't take place.
You can see how conda-forge build cartopy on Windows at https://github.com/conda-forge/cartopy-feedstock/blob/master/recipe/. The two important files:
https://github.com/conda-forge/cartopy-feedstock/blob/master/recipe/bld.bat
https://github.com/conda-forge/cartopy-feedstock/blob/master/recipe/cartopy.win.patch
Notice how that latter patch file renames the header dependency to geos.h, rather than geos_c.h because it is using the GEOS packaged by conda-forge. You may need to do a similar thing in your situation.
A history on this subject can also be found at https://github.com/SciTools/conda-recipes-scitools/issues/29#issuecomment-66497972.

Python pip install gives “Command ”python setup.py egg_info“ failed with error code 1”

Edit: Yes I know this question already exists, except my question is a bit different and none of the solutions fixed it.
I do most of my Python stuff when I'm at work and not on my personal machine, but I decided to install it on my personal computer as well. I fresh installed python 3.6.1, and created a virtual environment with virtualenv. Then within the virtualenv I tried to pip install urllib (or any module) and I received the error:
(pdbot) C:\Users\user\Documents\pdbot>pip install urllib
Collecting urllib
Using cached urllib-1.21.1.tar.gz
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Users\user\AppData\Local\Temp\pip-build-50tn0wlb\urllib\setup.py", line 191
s.connect((base64.b64decode(rip), 017620))
^
SyntaxError: invalid token
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\user\AppData\Local\Temp\pip-build-50tn0wlb\urllib\
I read elsewhere that this error had something to do with setuptools not being properly installed. So I ran this to attempt to fix the issue:
easy_install -U setuptools
I ended up receiving an even weirder error next:
(pdbot) C:\Users\zeke\Documents\pdbot>easy_install -U setuptools
Searching for setuptools
Reading https://pypi.python.org/simple/setuptools/
Downloading https://pypi.python.org/packages/a9/23/720c7558ba6ad3e0f5ad01e0d6ea2288b486da32f053c73e259f7c392042/setuptools-36.0.1.zip#md5=430eb106788183eefe9f444a300007f0
Best match: setuptools 36.0.1
Processing setuptools-36.0.1.zip
Writing C:\Users\zeke\AppData\Local\Temp\easy_install-jhg1val_\setuptools-36.0.1\setup.cfg
Running setuptools-36.0.1\setup.py -q bdist_egg --dist-dir C:\Users\zeke\AppData\Local\Temp\easy_install-jhg1val_\setuptools-36.0.1\egg-dist-tmp-8apak7kn
warning: no files found matching '*' under directory 'setuptools\_vendor'
Copying setuptools-36.0.1-py3.6.egg to c:\users\zeke\documents\pdbot\lib\site-packages
Adding setuptools 36.0.1 to easy-install.pth file
Installing easy_install-script.py script to c:\users\zeke\documents\pdbot\Scripts
Installing easy_install.exe script to c:\users\zeke\documents\pdbot\Scripts
error: [WinError 5] Access is denied: 'c:\\users\\zeke\\documents\\pdbot\\Scripts\\easy_install.exe'
This looks like a permissions error, but I ran these both in an administrator command prompt (Windows 10) and got the same result. I am the only user on this computer and I have all admin permissions. Is this virtualenv causing an issue? How do I remedy it?
EDIT: I was able to fix the permissions issue by leveraging the python executable like so:
python -m easy_install -U setuptools
But it didn't fix the python setup.py egg_info issue. I still get this error message when trying to pip install anything:
Command "python setup.py egg_info" failed with error code 1 in C:\Users\user\AppData\Local\Temp\pip-build-50tn0wlb\urllib\
I have tried both python -m pip install urllib and pip install urllib and neither work.
I had the same problem when trying to install urllib, but after doing a pip search urllib, I discovered that the problem was due to the version of urllib. From the search:
$ pip search urllib
...
> urllib5 (5.0.0) - Just increment the number and create a new lib. Never fix the original one.
At the end, a simple
pip install urllib5
within an elevated shell solved it.
Your problem has to do with permissions. The related/similar tools setup_tools, easy_install, and pip all tend to set a default set of permissions on files and folders they try to create in the package installation folder(s), rather than trying to match access permissions of the location they're installing in.
On Linux systems, where files and folders individually have permissions, this is frequently bypassed with the sudo command. On Windows, the equivalent is to run the installer as an Administrator. Since you're in the console, you have to open a console with Administrator privileges to run the pip command in.
Notable under Windows, the modules installed with pip from an Administrator console are still accessible to all users of the system that have the proper path in the PYTHONPATH system environment variable. Under Linux however, the problem is exacerbated by the fact that the files themselves may not be created with read and execute access for other users and may need to have their permissions manually modified after installation.
WARNING: urllib vs urllib2 vs urllibx
Both other answers claim that the problem is you're not specifying the correct "version" of the module in the call to pip. Neither is correct, as the error clearly indicates an installation folder access permissions violation causing the failure, but they also incorrectly recommended VERY unsafe behavior.
pip install urllib != pip install urllib5 these are two completely different packages.
The documentation for pip (https://packaging.python.org/tutorials/installing-packages/#id17) clearly says the way to specify a module version explicitly is pip install 'urllib==5'.
As part of how the package management engine implemented by pip works, running the command pip install urllib will always try to use the latest version of the urllib package, so you shouldn't need to specify the version unless you have some reason that you need a very specific version of the module.
There are two points to make in order to answer your question:
1. You are lucky you did not install that package!
The package you were trying to install was a maliciously created python package that was designed to look like a real package (in this case urllib3). If you had installed it, the package would have operated as normal except it would have sent some basic information about the system on which you installed the package to a URL (you can see more details on this here). You can read more about this fake package at either of the following links:
https://app.threatconnect.com/auth/incident/incident.xhtml?incident=5256822&owner=Common%20Community (you can sign up for a free account to view this one)
http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/index.html
Sending basic information about your systems to an unknown source isn't the worst thing you could do, but is certainly something you want to avoid when possible.
2. To properly install a package...
Specifically urllib:
To install urllib, you need to specify the version of the package you would like to install. For example, pip install urllib3.
Any package in general:
As #Elisabete Coelho suggested, you can use the pip search <package-name> feature to view the available packages. This is not perfect, however, as it may list malicious libraries like the one you were trying to install. A good guideline is that you should follow the installation instructions in a package's documentation closely to avoid any unforeseen issues. This is just an unfortunate necessity of living in a world where people make pretend python packages.

pystan: CompileError: command 'gcc' failed with exit status 1 (Windows)

Before I get to far into this, I should note that I have seen a very similar question, but the solution presented did not work for me. Perhaps one reason why is because that was Linux build and my current difficulty is on a Windows 7 machine. I use Cygwin to get access to the gcc (5.2.0) compiler suite.
In any event, I have been attempting to try out Stan via PyStan. I am working with an Anaconda (2.4.1 64-bit) distribution which I just updated today (Python 2.7.11). I initially tried to install PyStan via pip, but the install keeps failing due to what looks like the following error:
Cannot build msvcr library: "msvcr90d.dll" not found
Consequently, I used conda instead, which seemed to install just fine. (I should note that the conda install pushed my numpy back to an earlier version, which created conflicts with the pandas upon import. I just updated anaconda to deal with these broken dependencies.) I was also able to import PyStan without any problems. However, when I actually tried to fit a model (inside of a Jupyter Notebook), the process failed with the exception in the title.
The first thing I did was confirm that gcc was where in the referenced location (not shown in the title). Indeed it was, and it seemed to working just fine. I then tried to run the model as a script from the command line (still using Python), and it failed with the same error. When I recreated the model via the REPL, it pointed to a different location that had a .bat file referencing the (verified) compiler, and that failed as well.
I am pretty sure this is because I have Visual Studio 2012, instead of Visual Studio 2008. While it is possible for me to run parallel installations, if this code is going to be useful for others in the future, these are not reasonable hoops to jump through to make it happen. I was hoping that someone else might have a better explanation. Any info would be greatly appreciated.
Beneficial from the post at https://github.com/stan-dev/pystan/issues/306
I have met various error message, but finally, I install PyStan successfully.
My machine is also on Windows 7, x64 with Anaconda3 installed.Here are the procedures to install PyStan from the sourced codes.
Install Visual Studio 2017 & Visual Studio C++ Build Tool 2015 at http://landinghub.visualstudio.com/visual-cpp-build-tools
Update Conda
conda update conda
conda update --all
check the dependencies
pip install setuptool
conda install numpy cython matplotlib scipy pandas
Install gcc compiler components
conda install libpython
conda install -c msys2 m2w64-toolchain=5.3.0
created distutils.cfg file inside Anaconda3\Lib\distutils folder with the following:
[build]
compiler = mingw32
Download Git at https://git-scm.com/downloads
git clone --recursive https://github.com/stan-dev/pystan.git
Compile from the source code
python setup.py build --compiler=mingw32
python setup.py install
P.S. The solution for the issue: Cannot build msvcr library: "vcruntime140d.dll" not found.
Copy vcruntime140d.dll from C:\Windows\System32 to any folder, which is reachable in the path in the advanced system settings/environment variables/ system variables.

Installing Kartograph / GDAL / Etc. with PIP and virtualenv

Running into a few different problems here. Trying to install Kartograph and first installing dependencies. Here are my steps and results thus far:
Install GDAL from .pkg. Goes well. No problems here.
Try to install Kartograph using the default instructions for OSX with several packages. This fails with the following errors:
File "", line 4, in
main.gdal_config_error: [Errno 2] No such file or directory
Command python setup.py egg_info failed with error code 1 in
/Users/chris/ENV/build/GDAL
Ok, no dice. So then I try the install excluding GDAL as that seems to be presenting a problem to pip's install of Kartograph. That doesn't work either and produces the following errors:
raise KeyError('please set the environment variable PROJ_DIR to point to the location of your proj.4 installation')
KeyError: 'please set the environment variable PROJ_DIR to point to
the location of your proj.4 installation'
---------------------------------------- Command python setup.py egg_info failed with error code 1 in /Users/chris/ENV/build/pyproj
Now, I've edited the activate script of my virtualenv with the PYTHONPATH variable assignment per the Kartograph documentation. However, not sure that helped or has changed anything.
Has anyone run into a similar sequence of errors and if so, how did you solve this issue?
I managed to fix this error but now I'm stuck at another error.
Anyway this is what I did:
I installed the PROJ framework package from here:
http://www.kyngchaos.com/software/frameworks
Then I ran the following in Terminal to add the installation path to PROJ_DIR (as instructed in the error message):
$ export PROJ_DIR=$PROJ_DIR:/Library/Frameworks/PROJ.framework/Programs
Apparently PROJ is included in the GDAL framework so maybe the first step is unnecessary.
Update: It seems the path is lost when you close Terminal

Categories