Unable to get erpnext app v14

1

Executing the following command:
/frappe-bench$ bench get-app --branch version-14 erpnext

frappe 14.0.0.dev0 requires redis~=4.3.4, but you have redis 3.5.3 which is incompatible.

File “/home/ubuntu/frappe-bench/apps/frappe/frappe/utils/redis_wrapper.py”, line 7, in
from redis.commands.search import Search
ModuleNotFoundError: No module named ‘redis.commands’
ERROR:

Following is the bench version
$ bench --version
5.14.4

I have other instances of v14 running. This is happening on new installations.
How can i get a different version of frappe?

Thanks

2

Did you follow any tutorial to install erpnext?

3

I tried to chase this down, and got to a point where I believe I identified the problem, but don’t have enough chops to actually fix it. I’m trying to install this on my MacOS bare metal because I need to access a hardware device that requires access to the host network.

On a machine with Bench installed:

bench get-app erpnext --branch version-14

This returns the error you are finding:

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
frappe 14.0.0.dev0 requires redis~=4.3.4, but you have redis 3.5.3 which is incompatible.

Use the local pip3 in the Frappe Bench env/bin folder to list the redis versions:

bin % ./pip3 list | grep redis
hiredis                  2.0.0
redis                    3.5.3
redisearch               2.1.1

Just for fun, I tried to update the Frappe virtual python environment to a upgrade redis, which kinda works-ish:

bin % ./pip3 install redis --upgrade
Requirement already satisfied: redis in /Users/geordie/Code/Frappe/frappe-bench/env/lib/python3.11/site-packages (3.5.3)
Collecting redis
  Using cached redis-4.3.5-py3-none-any.whl (248 kB)
Requirement already satisfied: packaging>=20.4 in /Users/geordie/Code/Frappe/frappe-bench/env/lib/python3.11/site-packages (from redis) (21.3)
Requirement already satisfied: async-timeout>=4.0.2 in /Users/geordie/Code/Frappe/frappe-bench/env/lib/python3.11/site-packages (from redis) (4.0.2)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in /Users/geordie/Code/Frappe/frappe-bench/env/lib/python3.11/site-packages (from packaging>=20.4->redis) (3.0.9)
Installing collected packages: redis
  Attempting uninstall: redis
    Found existing installation: redis 3.5.3
    Uninstalling redis-3.5.3:
      Successfully uninstalled redis-3.5.3
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
rejson 0.5.6 requires redis==3.5.3, but you have redis 4.3.5 which is incompatible.
redisearch 2.1.1 requires redis==3.5.3, but you have redis 4.3.5 which is incompatible.
Successfully installed redis-4.3.5

Resulting in what appears to be an updated library:

bin % ./pip3 list | grep redis      
hiredis                  2.0.0
redis                    4.3.5
redisearch               2.1.1

Unfortunately, re-running

bench get-app erpnext --branch version-14

gives the exact same error. It appears that get-app updates the python VM.

I’m done for now - I gotta eat dinner. Hope this helps identify where the problem lies.

4

Not being a Python expert by any stretch of the imagination, it took me a while to figure out that the best way to deal with this seems to be using a Python Virtual environment:

https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/#creating-a-virtual-environment

There may be more elegant ways to do this, but this worked for me on Ubuntu 20.04.1

python3 -m pip install --user --upgrade pip
python3 -m pip --version
python3 -m pip install --user virtualenv

cd into the directory that has frappe-bench installed. In my case, it’s a Code directory.

cd ~/Code
python3 -m venv env
source env/bin/activate

It would be best to source env/bin/activate whenever you open a terminal to get your Python version to match. A more Unix-minded person would put that in .bashrc or .cshrc or one of the dozens of other shells that do precisely the same thing with completely different syntax.