Following this source I would like to install METIS and the Python wrapper in colab:
https://github.com/james77777778/metis_python
The installation steps are listed as the following:
Download and extract metis-5.1.0.tar.gz from METIS - Serial Graph Partitioning and Fill-reducing Matrix Ordering
cd metis-5.1.0
make config shared=1 prefix=~/.local/
make install
export METIS_DLL=~/.local/lib/libmetis.so
pip3 install metis-python
However, I'm not sure how to do steps 2-4 in colab specifically and so I get the following error:
RuntimeError: Could not locate METIS dll. Please set the METIS_DLL environment variable to its full path.
Thanks!
The issue seems to be the location of the libmetis.so file. Copying the file to /usr/lib and updating the path for the environmental variable successfully completes the process:
import requests
import tarfile
# Download and extract the file
url = "http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz"
response = requests.get(url, stream=True)
file = tarfile.open(fileobj=response.raw, mode="r|gz")
file.extractall(path=".")
# Change working directory
%cd metis-5.1.0
# The remaining steps as you have shown in the question, with updated path
!make config shared=1 prefix=~/.local/
!make install
!cp ~/.local/lib/libmetis.so /usr/lib/libmetis.so
!export METIS_DLL=/usr/lib/libmetis.so
!pip3 install metis-python
import metispy as metis
I am trying to generate Go source code from .proto file through this command:
protoc greet/greetpb/greet.proto --go-grpc_out=plugins=grpc:.
and, this is the directory structure:
greet/greetpb/greet.proto
I have tried all the answers mentioned here
But, none of them seems to be working.
I have verified that protoc-gen-go is in PATH.
Still, I am getting this:
protoc-gen-go-grpc: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--go-grpc_out: protoc-gen-go-grpc: Plugin failed with status code 1.
Additional details:
Go Version: go version go1.14.6 darwin/amd64
protoc version: libprotoc 3.12.3
My .zshrc file:
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export GOBIN=$GOPATH/bin
export PATH=$PATH:$GOROOT:$GOPATH:$GOBIN
We use cx_Freeze to produce standalone binary build of our python application under Mac OS. The build runs well under the build machine (which has Homebrew-and-Python installed), but failed in client machine with following error messages.
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/cx_Freeze/initscripts/__startup__.py", line 14, in run
module.run()
File "/usr/local/lib/python2.7/site-packages/cx_Freeze/initscripts/Console.py", line 26, in run
exec(code, m.__dict__)
File "./utest2.py", line 15, in <module>
from ttLib import *
File "ttLib.py", line 848, in init ttLib
import ctypes
File "/usr/local/Cellar/python#2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 7, in <module>
from _ctypes import Union, Structure, Array
ImportError: dlopen(/Users/gff/src/TextSeek_test/build/test_build/lib/_ctypes.so, 2): Symbol not found: __PySlice_AdjustIndices
Referenced from: /Users/gff/src/TextSeek_test/build/test_build/lib/_ctypes.so
Expected in: flat namespace
in /Users/gff/src/TextSeek_test/build/test_build/lib/_ctypes.so
By browsing stackoverflow answers about "__PySlice_AdjustIndices" and "flat namespace", we suspect this error was caused by the python conflict between system-default version and homebrew version.
Then we use "brew install python#2" in client machine, and the ctypes error disappeared. We run "brew uninstall python#2", this error returned back.
The question is : how can we embed necessary part of homebrew-python to bypass this ctype error?
We used "otool -L lib/_ctypes.so" to know the depenency of dynamic-linked file, it only showed out one file "/usr/lib/libSystem.B.dylib". This file seems to have no relation with python.
Any advice to move forward?
Dev Machine Info: Mac High Sierra, python 2.7.15 64bit. Use homebrew-python to build.
setup.py for cx_Freeze :
build_exe_options = {
"packages": ["wcwidth", "watchdog", "xlrd", "jinja2", "subprocess"],
"excludes": [ "AppKit", "Carbon", "CoreFoundation", "Finder", "Foundation", "FSEvents", "objc"],
"include_msvcr": True,
"zip_include_packages":["winshell", "wcwidth", "watchdog", "pyhk", "xlrd", "jinja2",\
"argh", "ctypes", "email", "encodings" ]
}
exeList = [Executable( "utest2.py", base = None, targetName= "utest") ]
setup( name = "XXX",
description = u"XXX desc",
options = {
"build_exe": build_exe_options,
'bdist_mac': {
'bundle_name': "XXX",
}
},
executables = exeList)
I found the solution by myself.
This issue is caused by wrongly linked dylib files. We use "otool -L" to find the dependency and re-link them with "install_name_tool -change" one by one. Finally the program works.
On the client machine, after installation of the frozen application, try to manually copy all dynamic libraries (.so, .dylib, ...?) which are in the lib subdirectory of the build directory into the build directory itself. Copy also all dynamic libraries which are in the build directory into its lib subdirectory. Does this solve the problem? On the build machine, you should of course use the same python version to produce the frozen application than you use to run the unfrozen application.
If 1. solves the problem, find out which dynamic libraries need to be copied in order that the application works (i.e. find out which of the manual copy actions you've done are really necessary). Use the include_files list of the build_exe options in your setup script to let cx_Freeze include the dynamic library automatically at the build step. You can use a tuple (source, destination) as item in the include_files list to let cx_Freeze copy a file from source to a specific destination into the build directory.
Explanation: I don't know Mac/OS. But I believe the issue you describe could be related to a similar issue with Microsoft Visual C++ Redistributable DLLs under Windows: cx_Freeze 5.1.1 includes packages in a lib subdirectory of the build directory, in the previous versions of cx_Freeze they used to be in the build directory itself. Some dynamic libraries need to be found in the build directory but are erroneously included in the lib subdirectory by cx_Freeze or vice versa. On the build machine it is usually not a problem, because a copy of the library is usually found in the system path, but on the client machine often no copy of the library can be found on the system path, or an incompatible one.
By the way the build_exe option "include_msvcr": True does not seem to work in cx_Freeze5.1.1, see this issue.
I am trying to run a test file in PyCharm with unittest.
It errors with this message:
FileNotFoundError: [Errno 2] No such file or directory: 'myfolder/opt/spark/./bin/spark-submit': 'myfolder/opt/spark/./bin/spark-submit'
I think it has something to do with my .bash_profile which a coworker helped configure. It looks like this:
export SPARK_HOME=myfolder/opt/spark
export PATH=$SPARK_HOME/bin:$PATH
export PATH=$HOME/.node_modules_global/bin:$PATH
# added by Anaconda3 5.1.0 installer
export PATH="/Users/myname/anaconda3/bin:$PATH"
Important to note, the path myfolder/opt/spark/./bin/spark-submit does not exist, but myfolder/opt/spark/bin/spark-submit does. I have no idea why the extra ./ is being added to the path.
from distutils.core import setup
import py2exe, sys, os
sys.argv.append('py2exe')
setup(
options = {'py2exe': {'bundle_files': 1}},
windows = [{'script': "single.py"}],
zipfile = None,
)
in this setup file for py2exe where it says single.py is that where I place the name of my program?
I don't know your py2exe tool, but we usually use this way to convert py to exe:
Download and install Standard Python Software:
http://www.python.org/download/
Download PyInstaller via link below:
http://pyinstaller.python-hosting.com/
Unpack the archive, that you have downloaded!
In this examople, the directory of the unpacked files:
In the <UNPACKED_FILES_DIR> directory, run Configure.py.
It must be run before trying to build anything.
Create a spec file for your project:
python Makespec.py -F -p <PYTHON_LIB_PATH> <PYTHON_SCRIPT>
-F: Produce a single file deployment.
-p <PYTHON_LIB_PATH>: Set base path for import (like using PYTHONPATH).
( e.g.: C:\Program Files\Python24\Lib\ )
<PYTHON_SCRIPT>: Path to python script.
6 Build your project!
python Build.py <SPECFILE>
<SPECFILE>: Path to the specfile, that have been created in step 4!
The full path to <SPECFILE>:
<UNPACKED_FILES_DIR>/<PYTHON_SCRIPT>/<PYTHON_SCRIPT>.spec
The binary file will be placed in the directory of <SPECFILE>.
If you can restrict your code, then Shed Skin, PyPy, or Cython make true, fast executables.
Py2exe, PyInstaller, or bbfreeze can package Python up to 2.7 into single executables.
Cx_Freeze packages Python up to 3.x into an executable plus many other files.
Yes. Are you making a windowing application or a console application? See the example setup.py files that came with py2exe.