user4074875
user4074875

Reputation: 146

Python 3.4 not recognising package

On my raspberry pi 3 model B I am running linux raspberrypi 4.4.48-v7 which is a debian distro/flavour.

I've installed python 3.4.

sudo pip install enum34

returns -

Requirement already satisfied: enum34 in /usr/local/lib/python3.4/dist-packages.

I'm attempting to install and run this open source project for microbot bluetooth interaction (but I believe my issue relates to python config)-

https://github.com/VRGhost/PyPush

I have installed the package and requirements but when I attempt to load/serve the package as follows-

./bin/serve.sh --ble_driver bluegiga --ble_device /dev/tty.usbmodem1 web_ui

I receive-

/usr/bin/python: No module named enum; 'PyPush' is a package and cannot be directly executed

I believe the line in serve.sh that is failing is-

exec python -m PyPush $*

How can I get python to recognise PyPush as a module? The stuff I've found online refers to enum34 which is installed.

Upvotes: 4

Views: 816

Answers (4)

rbaleksandar
rbaleksandar

Reputation: 9701

pip is for Python 2.x, pip3 is for Python 3.x. I also took a fast look to see what version of Python the PyPush is written for. Searching for print is often a fast way to do that. GitHub returned multiple results with print ... instead of print(...) which would mean that you have source code written in Python 2.x and not Python 3.x. You will have to switch to the 2.x.

The output

Requirement already satisfied: enum34 in /usr/local/lib/python3.4/dist-packages.

tells you that your enum package is installed for Python 3.x but at the same time you get

/usr/bin/python: No module named enum; 'PyPush' is a package and cannot be directly executed

The /usr/bin/python on most distros still stands for Python 2.x. You can check which version it is (2.x or 3.x) with /usr/bin/python --version just to make sure.

Long speech short - you have enum package for Python 3.x, PyPush is written for Python 2.x and you also need the backported enum for Python 2.x.

Upvotes: 1

John Christopher Jones
John Christopher Jones

Reputation: 509

In the particular case of enum34, you do not need it if you are trying to run Python 3.4. That particular package is a backport of Python 3.4's enum to earlier version of Python. You can just import enum in Python 3.4+.

You appear to have at least three versions of Python installed. It is normal to have two: Python 2.7 and Python 3.x. Each version has its own package repository and cannot see the others'. You appear to have installed a third custom installation.

When you run pip install enum34, the version of Python that is reported by pip --version gets the package. If python --version and which python are different then you will not be able to import the package, because it's not installed in that version's repository.

If you need to use the custom version of Python that you installed, you can probably run both it and the correct version of pip by prefixing your commands with /usr/local/bin/. E.g., /usr/local/bin/pip3.4 or /usr/local/bin/pip3 and /usr/local/bin/python3.4 or /usr/local/bin/python.

That said, I doubt you need this custom version of Python. You should really use your distribution's version or, failing that, add the official Python repositories to apt and install Python that way.

Your distribution is probably Raspbian, a flavor of Debian as you say. Debian comes with Python 3 and Python 2. These are installed in the system under /usr. You appear to have installed a third Python with some kind of external installer, version 3.4, which was installed under /usr/local.

Generally with Linux, you should always use your distribution's installers whenever possible. In the case of Debians, that means apt. If you read a tutorial that tells you to install software by running some script you extracted from some .tar.gz, probably don't. In the case of Debian, do an apt search to see if the version of the software you need is available and if not, see if the project (e.g., Python, Node, Yarn) has instructions for adding their official repositories to your distribution.

So, what's going wrong here is probably that you're running pip to install the enum34 package. That is probably Python 2.7's version of pip. You can verify this by running pip --version. My version uses Python 3.5, which you can see below:

$ pip --version pip 9.0.1 from /usr/local/lib/python3.5/site-packages (python 3.5) $

You can see that my version of Python 3 is installed in /usr/local/, but that's because I'm on macOS, where I'm installing Python 3 outside the control of the OS. On Debian, Python should almost always be installed via apt, which installs into /usr/.

Now, when you run pip install enum34, the version of Python that is reported by pip --version gets the package. If that isn't the same version as reported by python --version, then you won't be able to see the package when you run that version of python. It's still possible you have the same version of Python installed by the system and in a custom installation. When you run which pip and which python, those should also be in the same path. If which pip says /usr/local/bin/pip and which python says /usr/bin/python, you'll still have the same problem.

You can kind of ignore the problem by setting up a virtual environment, which you probably should anyway, but it's a bit of hassle. A virtual environment lets you maintain a separate set of Python packages for every project, which protects you from two projects needing different versions of the same package. As a consequence, it also protects you from accidentally using different versions of pip and python. However, it's kinda fiddly at first and I can't recommend ANY newbie guides to virtualenv.

Upvotes: 4

Mani
Mani

Reputation: 5648

It seems that the package path is not accessible. Do the following.

  1. check whether python scans /usr/local/lib/python3.4/dist-packages for libs. You can check this simply by printing import sys;print (sys.path) it gives you a list of paths where python scans for libraries. If path is not there add the path.
  2. check by default which version of python is being used python2.7 or python3 by defaultpython refers python2.7. Also, Python 2.7 libraries are not accessible by python 3 refer this for changing default python version.
  3. By default pip installs libraries for python2 so use pip3 for installing packages for python3. check where pip has installed libraries in your case and also check whether those paths are accessible using point 1.
  4. Some times when scripts are called by shell scripts there are possibilities in executing those scripts as different user (ex: normal user, root) in that case all those environment configurations like shell,path changes. check all the above mentioned points in such case.

I'm sure if you check these 4 points your issue will be resolved. My guess is either your problem should be point 1 or 4.

Upvotes: 3

Mirek Długosz
Mirek Długosz

Reputation: 4285

Something is seriously broken with places where your Python looks for files.

There are two versions of Python - legacy Python 2 and current Python 3. By default, python executable (/usr/bin/python) points to Python 2 and pip executable is for Python 2 modules. Python 3 uses python3 and pip3, respectively.

However, your pip (used for Python2) finds module installed in /usr/local/lib/python3.4/dist-packages. It should not look there to begin with.

I don't know how you ended up in that situation, but it is salvageable with help of virtual environment. Just create new virtual env, activate it, install all dependencies and run command again:

virtualenv --always-copy --python=python2 /path/to/virtualenv/directory
source activate /path/to/virtualenv/directory
pip install -r requirements/prod.txt
./bin/serve.sh --ble_driver bluegiga --ble_device /dev/tty.usbmodem1 web_ui

If you don't have virtualenv command available, install it with

apt install virtualenv

Upvotes: 1

Related Questions