Repository: freqtrade/freqtrade
Pull request: Gym aid
Refer to https://github.com/freqtrade/freqtrade/pull/8080

@xmatthias , do you think this way could be any useful for newcomers?

Problem statement:
Running setup.py install for gym did not run successfully.
  Running setup.py install for gym ... error
  error: subprocess-exited-with-error

  

## environment

  * Operating system: ubuntu-22.04.1-live-server
  * Python Version: python3
  
## Describe the problem:
Hello ! 
I try to setup freqtrade on ProxmoxVM-ubuntu-22.04.1-live-server

get this error :

× Running setup.py install for gym did not run successfully.
  │ exit code: 1
  ╰─> [1 lines of output]
      error in gym setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> gym

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.
Failed installing dependencies

Hints from issue discussion:
To be honest - i think `note: This is an issue with the package mentioned above, not pip.` says it all.

We'll need some more info though - for example the output of `python3 --version`  and `python -m pip --version` - as well as the system architecture (arm/amd64, ...).

There's a bug report for this in the gym repo already: https://github.com/openai/gym/issues/3176
The error message indicates that the value of the extras_require argument in the setup.py file for the gym package is not formatted correctly.

To resolve the issue, you need to make sure the extras_require argument is a dictionary where the keys are the feature names and the values are strings or lists of strings representing the required packages. The strings should contain valid project and version requirement specifiers (e.g. "package_name>=version").

Here's an example of a correctly formatted extras_require argument:


extras_require = {
    "feature_A": ["package_A>=1.0"],
    "feature_B": ["package_B>=2.0", "package_C>=3.0"],
}
Once you have corrected the extras_require argument, try running the setup.py install command again to see if the error is resolved.
@rashiddaha yes - but that change needs to happen in gym (not freqtrade) - which is an old version (because sb3-baseline didn't update to a newer gym release yet).

I suspect this issue will now ripple through the different chains - ultimately ending with either pinning setuptools to a lower version - or a new minor release of gym==0.21.x - fixing this issue.
@xmatthias Yes, You can Try By Changing the Version as well. 
I have shared this solution on Upwork (Muhammad Rashid).
Hello
I can solve this solutuin.
Hi, I can do it

Commit message: Add to setup

Patch to review:
diff --git a/requirements-freqai-rl.txt b/requirements-freqai-rl.txt
index 82ff4022dc8..cb77a34c137 100644
--- a/requirements-freqai-rl.txt
+++ b/requirements-freqai-rl.txt
@@ -6,4 +6,5 @@ torch==1.13.1
 stable-baselines3==1.7.0
 sb3-contrib==1.7.0
 # Gym is forced to this version by stable-baselines3.
+setuptools==65.5.0 # Should be removed when gym is fixed.
 gym==0.21
diff --git a/setup.sh b/setup.sh
index 4cb50485377..846d9e2a960 100755
--- a/setup.sh
+++ b/setup.sh
@@ -1,6 +1,30 @@
 #!/usr/bin/env bash
 #encoding=utf8
 
+# This should be deleted as soon as a gym release with a fixed setuptools is made
+function check_is_new_setuptools_installed() {
+  stoolversion=$(${PYTHON} -m pip show setuptools | grep "Version:")
+  stoolversion=${stoolversion##* }
+  stoolversion=$(echo $stoolversion | grep -Eo "^[0-9]+")
+
+  if [ $stoolversion -gt 65 ]; then
+    echo "You are using a new version of setuptools. This is not supported by gym at the moment."
+    read -p "Do you want to downgrade setuptools to a version that is supported by gym? [y/N] "
+
+    if [[ $REPLY =~ ^[Yy]$ ]]
+    then
+      ${PYTHON} -m pip install setuptools==65.5.0
+      if [ $? -ne 0 ]; then
+        echo "Failed downgrading setuptools"
+        exit 1
+      fi
+    else
+      echo "Please downgrade setuptools to a version that is supported by gym."
+      exit 1
+    fi
+  fi
+}
+
 function echo_block() {
     echo "----------------------------"
     echo $1
@@ -60,7 +84,7 @@ function updateenv() {
     fi
     REQUIREMENTS_HYPEROPT=""
     REQUIREMENTS_PLOT=""
-     read -p "Do you want to install plotting dependencies (plotly) [y/N]? "
+    read -p "Do you want to install plotting dependencies (plotly) [y/N]? "
     if [[ $REPLY =~ ^[Yy]$ ]]
     then
         REQUIREMENTS_PLOT="-r requirements-plot.txt"
@@ -278,6 +302,7 @@ function help() {
 
 # Verify if 3.8+ is installed
 check_installed_python
+check_is_new_setuptools_installed
 
 case $* in
 --install|-i)


Code review comments:
diff_hunk: @@ -1,6 +1,30 @@
 #!/usr/bin/env bash
 #encoding=utf8
 
+# This should be deleted as soon as a gym release with a fixed setuptools is made
+function check_is_new_setuptools_installed() {
+  stoolversion=$(${PYTHON} -m pip show setuptools | grep "Version:")
+  stoolversion=${stoolversion##* }
+  stoolversion=$(echo $stoolversion | grep -Eo "^[0-9]+")
+
+  if [ $stoolversion -gt 65 ]; then
+    echo "You are using a new version of setuptools. This is not supported by gym at the moment."
+    read -p "Do you want to downgrade setuptools to a version that is supported by gym? [y/N] "
+
+    if [[ $REPLY =~ ^[Yy]$ ]]
+    then
+      ${PYTHON} -m pip install setuptools==65.5.0
path: setup.sh
text: @user1:
If i'm honest, then my approach would've been to force this downgrade if freqai-rl (or dev) is selected (we do something similar with cython for raspberry installations).

It's not really optional - and we know for a fact that installation will fail if this requirement is not matched - so we're basically asking the user "would you like to have the installation fail - or not?" - without saying it out loud 😆 

It's not a global downgrade anyway, and will only impact the current virtual environment - so it's not problematic i'd think.



@author:
So that's a funny thing. In the fresh, newly created venv the version is actually `59.6.0` it doesn't even pass the check if that check is after `source .env/bin/activate`. Maybe we can only leave it in the freqai requirements for the setup.sh. It will still not work if trying to install system-wide (through `pip install -r ....`). It will only work in setup.sh.

@author:
Still again even if the version is `59.6.0` in venv if the version is not fixed in the requirement it fails to build gym.

@author:
Ok, can't get simpler than that, just let people know in the docs haha

@user1:
that obviously works 😆 

i did a few tests (always on clear systems) - and found a working method for the setup.sh script.
combined with the documentation - that will have to suffice.

@author:
Looks great, thank you for getting to the bottom of this :)