We Keep Coding

Running with python instead of python3 in Ubuntu

I run Linux via ubuntu in windows. My terminal has python3 instead of python. I am using a package named PASTA, which uses commands with python as:
python run_pasta.py -i input_fasta
Since, I have python3, I am trying to run it this way:
python3 run_pasta.py -i ALL_FASTA.fasta -d protein --aligner=probcons
which gives me the following error, could anyone please tell how to fix this?
PASTA INFO: Performing initial alignment of the entire data matrix...
PASTA failed because one of the programs it tried to run failed. The
invocation that failed was:
"/mnt/f/Projects/WoldringLab/AnalyzingGenerativeModel/pasta-code/pasta/bin/hmmeralign"
"/home/aryaman3900/.pasta/pastajob/temp569cp9x3/init_aln/temphmmeralignourpmnyw/input.fasta"
"/home/aryaman3900/.pasta/pastajob/temp569cp9x3/init_aln/query-0.fasta"
"/home/aryaman3900/.pasta/pastajob/temp569cp9x3/init_aln/temphmmeralignourpmnyw/input.aligned"
"amino"
/usr/bin/env: ‘python’: No such file or directory

You can create a symlink (symbolical link) from python3 to python. What this will do is just to map each call to /usr/bin/python to your python3 executable:
sudo ln -s $(which python3) /usr/bin/python
You can learn more about the ln command by reading its man page via man ln.

How to update libstdc++.so.6 or change the file to use on Tensorflow, Python

I am using Python3 and Tensorflow 1.15 on Apache server CentOS6.
Now, I am Struggling with this error.
It requires GLIBCXX_3.4.17
ImportError: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.17' not found (required by /home/app/anaconda3/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_tensorflow_internal.so)
So,Now I checked the libstdc version.
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
There is no 3.4.17
However in conda directory, there is another libstdc++ too
strings /home/app/anaconda3/lib/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_DEBUG_MESSAGE_LENGTH
So I have two ideas.
update /usr/lib/64/libstdc++.so.6 on CentOS6
sudo yum update libstdc++-devel
no package found...
force python to use /home/app/anaconda3/lib/libstdc++.so.6
However I have no idea how to ....
If you have any ideas, Please help..

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic which explains how to ensure a newer libstdc++.so.6 is found by the linker.
Also the libstdc++ FAQ at https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths

Cmake seems not to use the Python interpreter it confirms it uses

I have the following CMakeLists.txt file, which is instructed to use Python 3.4
cmake_minimum_required(VERSION 3.2 FATAL_ERROR)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/../cmake/")
project(aConfigd VERSION 1.0)
string(TOLOWER aConfigd project_id)
find_package(PythonInterp 3.4 REQUIRED)
include(FindPythonInterp)
set(PYTHON ${PYTHON_EXECUTABLE})
message(STATUS "\${PYTHON_EXECUTABLE} == ${PYTHON_EXECUTABLE}")
set(pkgdatadir /usr/share/configd)
set(configdir /etc/amy)
set(SONARCONFIGID_SOURCE_DIR etc/configd)
set(SRC_DIR configd/src/)
include(common)
# "${SRC_DIR}/systemd_client.py"
# "${SRC_DIR}/amyconfig_service.py"
"${SRC_DIR}/__init__.py"
"${SRC_DIR}/main.py"
"${SRC_DIR}/application.py"
DESTINATION ${pkgdatadir}/configd/
)
#general
set(CPACK_PACKAGE_NAME "a-config")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "a-config-manager")
set(CPACK_PACKAGE_DESCRIPTION "a-config-manager")
# redhat
set(CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
/etc/amy
)
include(cpack)
Indeed, it confirms that ${PYTHON_EXECUTABLE} == /usr/bin/python3.4 (see 4th line below):
$ make clean ; cmake -DCMAKE_BUILD_TYPE=Release -DSHORT_VERSION=NO -DCUSTOMER=NO .. ; make -j12 ; make package
-- Found PythonInterp: /usr/bin/python3.4 (found suitable version "3.4.5", minimum required is "3.4")
-- Found PythonInterp: /usr/bin/python3.4 (found version "3.4.5")
-- ${PYTHON_EXECUTABLE} == /usr/bin/python3.4
-- Build Type: Release
-- Detected distribution: rhel fedora
-- Detected aConfigd version: 2.3.0-3030-gf7733cf659
-- Detected distribution: rhel fedora
-- Configuring done
-- Generating done
-- Build files have been written to: /local/raid0/git/amy/aConfig/build
Run CPack packaging tool...
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: aConfigd
CPack: - Install project: aConfigd
CPack: Create package
CPackRPM:Warning: CPACK_SET_DESTDIR is set (=ON) while requesting a relocatable package (CPACK_RPM_PACKAGE_RELOCATABLE is set): this is not supported, the package won't be relocatable.
CPackRPM: Will use GENERATED spec file: /local/raid0/git/my/aConfig/build/_CPack_Packages/Linux/RPM/SPECS/a-config.spec
CPack: - package: /local/raid0/git/my/aConfig/build/a-config-2.3.0-3030-gf7733cf659.el7.my.x86_64.rpm generated.
$
However, if I uncomment the "${SRC_DIR}/systemd_client.py" line, I get the error:
Compiling /local/raid0/git/my/aConfig/build/_CPack_Packages/Linux/RPM/a-config-2.3.0-3030-gf7733cf659.el7.my.x86_64/usr/share/configd/configd/systemd_client.py ...
File "/usr/share/configd/configd/systemd_client.py", line 21
def __init__(self, systemd_proxy:Gio.DBusProxy):
^
SyntaxError: invalid syntax
Isn't def __init__(self, systemd_proxy:Gio.DBusProxy): a valid Python 3.4 syntax?
If yes, why does Cmake complains?

The root-cause occurs in the rpmbuild step.
RPM is trying to be extra-helpful, and tries to (byte-code) compile .py files it encounters.
Alas, it wrongly uses the python2 interpreter to create a file's byte-code (even though find_package(PythonInterp 3.4 REQUIRED) is declared in the CMakeLists.txt file).
The fix that worked for me was:
set(CPACK_RPM_BUILDREQUIRES python34-devel)
set(CPACK_RPM_SPEC_MORE_DEFINE "%define __python ${PYTHON_EXECUTABLE}")

When you just run "${SRC_DIR}/systemd_client.py", you're telling it to run that script the same way it would be run by the shell: by looking at the #! line and running it with whatever interpreter is specified there. Which is probably something like #! /usr/bin/python or #! /usr/bin/env python.
If you want to run your script with a particular interpreter, you have to run that interpreter and pass it the script—just as you would at the shell. I'm pretty rusty with CMake, but I'd assume you do that like this:
"${PYTHON_EXECUTABLE}" "${SRC_DIR}/amyconfig_service.py"
Alternatively, since this is your code, maybe you want to use setuptools to programmatically generate scripts for your entry-points, which means it would create a #! line for them that runs whichever Python version was used to run setup.py.

Matlab pyversion command can not find library for python3.4

I want call python3.4 from the matlab. The default version is python2.7, when I run pyversion in matlab, it shows :
version: '2.7'
executable: '/usr/bin/python'
library: 'libpython2.7.so.1.0'
home: '/usr'
isloaded: 0
and I tested by run py.list() in matlab, it works.
Then I want to change the version to python3, so I run
pyversion(/usr/bin/python3)
to change the version of python.
But now py.list() can not works, is said Undefined variable "py" or class "py.list"..
Additionally, now I run pyversion, the information shows :
version: '3.4'
executable: '/usr/bin/python3.4'
library: ''
home: '/usr'
isloaded: 0
the "library" becomes empty.
How could I solve this to run python3.4 correctly?
I use Ubuntu 14.04 and I have installed Cython for python3.4. I have the following output by running find /usr/lib -name libpython*
/usr/lib/python3.4/config-3.4dm-x86_64-linux-gnu/libpython3.4.so
/usr/lib/python3.4/config-3.4dm-x86_64-linux-gnu/libpython3.4dm.so
/usr/lib/python3.4/config-3.4dm-x86_64-linux-gnu/libpython3.4dm.a
/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu/libpython3.4.so
/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu/libpython3.4m.a
/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu/libpython3.4m.so
/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu/libpython3.4m-pic.a
/usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7.so
/usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7.a
/usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7-pic.a
/usr/lib/libpeas-1.0/loaders/libpython3loader.so
/usr/lib/libpeas-1.0/loaders/libpythonloader.so
/usr/lib/debug/usr/lib/libpython3.4m.so.1.0-gdb.py
/usr/lib/debug/usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
/usr/lib/libreoffice/program/libpythonloaderlo.so
/usr/lib/x86_64-linux-gnu/libpython3.4m.so.1
/usr/lib/x86_64-linux-gnu/libpython3.4dm.so.1
/usr/lib/x86_64-linux-gnu/libpython3.4m.a
/usr/lib/x86_64-linux-gnu/libpython2.7.so
/usr/lib/x86_64-linux-gnu/libpython3.4m.so
/usr/lib/x86_64-linux-gnu/libpython3.4dm.so.1.0
/usr/lib/x86_64-linux-gnu/libpython2.7.a
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1
/usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0
/usr/lib/x86_64-linux-gnu/libpython3.4dm.so
/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
/usr/lib/x86_64-linux-gnu/libpython3.4dm.a

Just so happened to have the same issue within 5 days of this post.
Apparently matlab uses the following script to search for the library:
MATLABROOT/toolbox/matlab/external/interfaces/python/+python/+internal/pyinfo.py
where MATLABROOT is something you chose when you installed matlab.
Theoretically, you could edit pyinfo.py to include '/usr/lib/x86_64-linux-gnu' in its search. For example, by appending one more method to the search locations that just returns '/usr/lib/x86_64-linux-gnu'. But I don't know what the licensing/legal/warranty ramifications of this would be, so use at your own discretion.

I ran into a similar issue (R2015b, Ubuntu) and did not solve it with the accepted answer. I had to execute
python3 MATLABROOT/toolbox/matlab/external/interfaces/python/+python/+internal/pyinfo.py
without modifying it from the command line to make it work.

Run python:
>>> import sys
>>> print(sys.executable)
Copy the answer and use it in Matlab as follow:
>> pyversion('C:\Users\84757\AppData\Local\Programs\Python\Python38\python.exe');

MIDI on Python / PyGame, Ubuntu 12.04

Trying to get a MIDI interface to work with pygame on Ubuntu 12.04. I know the keyboard works because it can control vkeybd and works with PyGame on OSX, so the issue with with MIDI in python.
$ python -m pygame.examples.midi --list
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/lib/python2.7/dist-packages/pygame/examples/midi.py", line 820, in <module>
print_device_info()
File "/usr/lib/python2.7/dist-packages/pygame/examples/midi.py", line 25, in print_device_info
pygame.midi.init()
File "/usr/lib/python2.7/dist-packages/pygame/midi.py", line 71, in init
import pygame.pypm
ImportError: /usr/lib/libportmidi.so.0: undefined symbol: snd_seq_event_input_pending
python-pygame installed through the package manager, as is python-pm.
Any ideas? :)

Although this won't exactly answer your question, it may help you debug the problem yourself.
The error is this :
ImportError: /usr/lib/libportmidi.so.0: undefined symbol: snd_seq_event_input_pending
The undefined symbol is a failure of the dynamic linker to find the code required for the snd_seq_event_input_pending function.
On an example 32 bit Oneiric system we can do this to look at some symbols of libportmidi.so.0.
nm -DC /usr/lib/libportmidi.so.0 | grep snd_seq_event_input_pending
U snd_seq_event_input_pending
This tells us that the libportmidi library requires the code for snd_seq_event_input_pending but the symbol is undefined. So for libportmidi to function it must also load an additional library which contains this function.
On Oneiric I've found that this symbol is defined in libasound2.so.2.
nm -DC /usr/lib/i386-linux-gnu/libasound.so.2 | grep snd_seq_event_input_pending
000a0fa0 T snd_seq_event_input_pending
The T indicates that the function exists and is in the text (code) segment.
Usually, linking of associated libraries occurs automatically as libasound.so.2 should be referenced by libportmidi. On the same system.
ldd /usr/lib/libportmidi.so.0
....
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0x00e35000)
which shows that libmidi depends on libasound. In the ldd output list in your comments there is no reference to libasound, and so it won't try to automatically dynamically link libasound.so.2 when it is loaded, resulting in your error.
There's a few reasons why there may be an error:
The way linking from libportmidi may have change from Oneiric to Precise. eg libportmidi may attempt to find its own dependencies for libasound. (Unlikely).
There is a bug in packaging of libportmidi where it doesn't reference libasound.so.2 as it should. This may be platform specific (eg only an error on 64 bit systems).
I'd suggest that you try to find out the library on your system that contains the snd_seq_event_input_pending function and then work backwards to try and determine why it has not been linked with libportmidi.
The following bash command will help you find the libaries implementing snd_seq_event_input_pending. If you don't find anything, there's a problem with the libraries installed on your machine.
find /lib /usr/lib -name "lib*.so.*" | while read f; do
if nm -DC "$f" | grep -q 'T snd_seq_event_input_pending'; then
echo "$f"
fi
done

I have exactly the same problem (on Ubuntu 12.04.1), using e.g. the MIDI playback tool in Frescobaldi (which is a Python application). This used to work fine, but doesn't anymore.
This is quite obviously a miscompiled portmidi package which was pushed out on on 2013-01-25, see https://launchpad.net/ubuntu/+source/portmidi/1:200-0ubuntu1.12.04.1. Downgrading to the previous 1:200-0ubuntu1 package solved the issue for me.
I guess that the proper course of action would be to file a bug report against the 1:200-0ubuntu1.12.04.1 version on Launchpad at https://bugs.launchpad.net/ubuntu/+source/portmidi/+bugs. If it doesn't get fixed, we might also ask falkTX if he would be willing to provide a working package in his KXStudio PPAs instead.
Just for the record, here's what ldd gives for the 1:200-0ubuntu1 libportmidi on my system:
linux-vdso.so.1 => (0x00007fffe9bff000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f26264cb000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f26262ae000)
libporttime.so.0 => /usr/lib/libporttime.so.0 (0x00007f26260ab000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2625cec000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f26259f0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f26257eb000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f26255e3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f26269f4000)
And the broken 1:200-0ubuntu1.12.04.1 version:
linux-vdso.so.1 => (0x00007fff9e3ff000)
libporttime.so.0 => /usr/lib/libporttime.so.0 (0x00007fb84ac71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb84a8b2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb84a694000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb84b0af000)
So any application which doesn't happen to link in libasound2 by itself will be hosed. Specifically, that seems to be the case for the Python portmidi module. (This kind of error is also aggravated by the fact that, at least from Ubuntu 12.04 onwards, gcc uses the --as-needed linker flag by default. I bet that there are still quite a few packages in the Ubuntu repos which are broken because of that.)

If you want fix it now you can checkout the latest version of portmidi and build the library as follows (assuming you've checked out or unpacked portmidi into a dir called portmidi):
cd portmidi
make -f pm_linux/Makefile
The default install doesn't build a dynamic version of library so you need to build one like this:
gcc -shared -Wl,-soname,libportmidi.so.0 -o pm_linux/libportmidi.so.0 pm_common/pmutil.o pm_linux/pmlinuxalsa.o pm_linux/pmlinux.o pm_common/portmidi.o -lasound
Then you can make a copy of the old library (just in case), and then copy this new one in its place:
sudo cp /usr/lib/libportmidi.so.0 /usr/lib/libportmidi.so.0.orig
sudo cp pm_linux/libportmidi.so.0 /usr/lib/libportmidi.so.0
Your apps should now work...