Python 3.4 not recognising package

Question

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.

Answer 1

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.

Answer 2

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.