Error during installation: Building wheel for mujoco-py (PEP 517)

I successfully installed MuJoCo using pip3 install -U 'mujoco-py<2.1,>=2.0'
I got this warning, but it still installed fine and works:
  WARNING: Missing build requirements in pyproject.toml for mujoco-py<2.1,>=2.0 from https://files.pythonhosted.org/packages/a2/30/21abd0cf2734bf5f34a7a8967789b12dee55f1e51e9c1c60af1cba549123/mujoco-py-<IP_ADDRESS>.tar.gz#sha256=6ae20ca9509203758f5e30a7a4019cb2d581b6d40dc2c2669dbe3229cfdf05e8.
  WARNING: The project does not specify a build backend, and pip cannot fall back to setuptools without 'wheel'.

When I try to install safety-gym with pip3 install -e ., I get the same warning as above, but then I get an error. At the end it says HINT: On OS X, install GCC with brew install gcc, but gcc is already installed and up to date. Reinstalling did not help. Any advice?
Here is the entire output:
Collecting gym~=0.15.3
  Using cached https://files.pythonhosted.org/packages/1d/85/a7a462d7796f097027d60f9a62b4e17a0a94dcf12ac2a9f9a913333b11a6/gym-0.15.4.tar.gz
Collecting joblib~=0.14.0
  Using cached https://files.pythonhosted.org/packages/28/5c/cf6a2b65a321c4a209efcdf64c2689efae2cb62661f8f6f4bb28547cf1bf/joblib-0.14.1-py2.py3-none-any.whl
Collecting mujoco_py==<IP_ADDRESS>
  Using cached https://files.pythonhosted.org/packages/c3/a1/00f5482d6325565f35a81707b8c6b3e364bdc8f7b9487c15c18781e1432a/mujoco-py-<IP_ADDRESS>.tar.gz
  Installing build dependencies ... done
  WARNING: Missing build requirements in pyproject.toml for mujoco_py==<IP_ADDRESS> from https://files.pythonhosted.org/packages/c3/a1/00f5482d6325565f35a81707b8c6b3e364bdc8f7b9487c15c18781e1432a/mujoco-py-<IP_ADDRESS>.tar.gz#sha256=2a294006c66ed225c3409b9d60a91afeb7756f96fecf3d8c22116d00adf6d82a (from safety-gym==0.0.0).
  WARNING: The project does not specify a build backend, and pip cannot fall back to setuptools without 'wheel'.
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
    Preparing wheel metadata ... done
Collecting numpy~=1.17.4
  Using cached https://files.pythonhosted.org/packages/9e/cf/7cea38d32df6087d7c15bca8edef0be82e0d957119e9dafd7052dc6192f0/numpy-1.17.4-cp38-cp38-macosx_10_9_x86_64.whl
Collecting xmltodict~=0.12.0
  Using cached https://files.pythonhosted.org/packages/28/fd/30d5c1d3ac29ce229f6bdc40bbc20b28f716e8b363140c26eff19122d8a5/xmltodict-0.12.0-py2.py3-none-any.whl
Collecting scipy
  Using cached https://files.pythonhosted.org/packages/90/d2/44b70a930ad28da8f65d8c294ac88b20f561e5d650b85efea80381566db1/scipy-1.4.1-cp38-cp38-macosx_10_9_x86_64.whl
Requirement already satisfied: six in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from gym~=0.15.3->safety-gym==0.0.0) (1.13.0)
Collecting pyglet<=1.3.2,>=1.2.0
  Using cached https://files.pythonhosted.org/packages/1c/fc/dad5eaaab68f0c21e2f906a94ddb98175662cc5a654eee404d59554ce0fa/pyglet-1.3.2-py2.py3-none-any.whl
Collecting cloudpickle~=1.2.0
  Using cached https://files.pythonhosted.org/packages/c1/49/334e279caa3231255725c8e860fa93e72083567625573421db8875846c14/cloudpickle-1.2.2-py2.py3-none-any.whl
Collecting opencv-python
  Using cached https://files.pythonhosted.org/packages/c8/e8/bcef356c7f89433a5f4e631bbe898d03ba79d1c06a5d779829a10ddf16e8/opencv_python-<IP_ADDRESS>-cp38-cp38-macosx_10_9_x86_64.whl
Requirement already satisfied: imageio>=2.1.2 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (2.6.1)
Requirement already satisfied: Cython>=0.27.2 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (0.29.14)
Requirement already satisfied: glfw>=1.4.0 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (1.8.7)
Requirement already satisfied: cffi>=1.10 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (1.13.2)
Requirement already satisfied: fasteners~=0.15 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (0.15)
Collecting future
  Using cached https://files.pythonhosted.org/packages/45/0b/38b06fd9b92dc2b68d58b75f900e97884c45bedd2ff83203d933cf5851c9/future-0.18.2.tar.gz
Requirement already satisfied: pillow in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from imageio>=2.1.2->mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (6.2.1)
Requirement already satisfied: pycparser in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from cffi>=1.10->mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (2.19)
Requirement already satisfied: monotonic>=0.1 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from fasteners~=0.15->mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (1.5)
Building wheels for collected packages: mujoco-py
  Building wheel for mujoco-py (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/tmpv4_0jd48
       cwd: /private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py
  Complete output (49 lines):
  running bdist_wheel
  running build
  Removing old mujoco_py cext /private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/generated/cymj_<IP_ADDRESS>_38_macextensionbuilder_38.so
  Traceback (most recent call last):
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in <module>
      main()
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 181, in build_wheel
      return _build_backend().build_wheel(wheel_directory, config_settings,
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 208, in build_wheel
      return self._build_with_temp_dir(['bdist_wheel'], '.whl',
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 194, in _build_with_temp_dir
      self.run_setup()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 236, in run_setup
      super(_BuildMetaLegacyBackend,
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 142, in run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 33, in <module>
      setup(
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/__init__.py", line 145, in setup
      return distutils.core.setup(**attrs)
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/dist.py", line 966, in run_commands
      self.run_command(cmd)
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/dist.py", line 985, in run_command
      cmd_obj.run()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/normal/lib/python3.8/site-packages/wheel/bdist_wheel.py", line 192, in run
      self.run_command('build')
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/cmd.py", line 313, in run_command
      self.distribution.run_command(command)
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/dist.py", line 985, in run_command
      cmd_obj.run()
    File "setup.py", line 29, in run
      import mujoco_py  # noqa: force build
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/__init__.py", line 3, in <module>
      from mujoco_py.builder import cymj, ignore_mujoco_warnings, functions, MujocoException
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 506, in <module>
      cymj = load_cython_ext(mujoco_path)
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 105, in load_cython_ext
      cext_so_path = builder.build()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 221, in build
      built_so_file_path = self._build_impl()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 324, in _build_impl
      raise RuntimeError(
  RuntimeError: Could not find GCC executable.

  HINT: On OS X, install GCC with `brew install gcc`. or `port install gcc`.
  ----------------------------------------
  ERROR: Failed building wheel for mujoco-py
  Running setup.py clean for mujoco-py
Failed to build mujoco-py
ERROR: Could not build wheels for mujoco-py which use PEP 517 and cannot be installed directly

+1

This worked after installing an older version of gcc

Thanks! I got the error fixed after following the troubleshooting instructions for Mac in mujoco-py

change setup mujoco-py version from <IP_ADDRESS> to <IP_ADDRESS>; <IP_ADDRESS> has not been released yet

Which version of gcc did you use ?

4.2.1 now

thx

I have a similar problem, how did you downgrade to an older gcc version?

I have faced the same issue. The above did not work for me. Has anyone found a solution? Thanks

If you're trying tu use opencv with cuda, forget python and use c++ opencv::cuda libraries

The problem is with installing safety-gym.
ERROR: Failed building wheel for mujoco-py

macOS users: this error is cases by mujoco's c compiler. There is no symbolic link between gcc and clang.

I successfully installed MuJoCo using pip3 install -U 'mujoco-py<2.1,>=2.0'
I got this warning, but it still installed fine and works:
  WARNING: Missing build requirements in pyproject.toml for mujoco-py<2.1,>=2.0 from https://files.pythonhosted.org/packages/a2/30/21abd0cf2734bf5f34a7a8967789b12dee55f1e51e9c1c60af1cba549123/mujoco-py-<IP_ADDRESS>.tar.gz#sha256=6ae20ca9509203758f5e30a7a4019cb2d581b6d40dc2c2669dbe3229cfdf05e8.
  WARNING: The project does not specify a build backend, and pip cannot fall back to setuptools without 'wheel'.

When I try to install safety-gym with pip3 install -e ., I get the same warning as above, but then I get an error. At the end it says HINT: On OS X, install GCC with brew install gcc, but gcc is already installed and up to date. Reinstalling did not help. Any advice?
Here is the entire output:
Collecting gym~=0.15.3
  Using cached https://files.pythonhosted.org/packages/1d/85/a7a462d7796f097027d60f9a62b4e17a0a94dcf12ac2a9f9a913333b11a6/gym-0.15.4.tar.gz
Collecting joblib~=0.14.0
  Using cached https://files.pythonhosted.org/packages/28/5c/cf6a2b65a321c4a209efcdf64c2689efae2cb62661f8f6f4bb28547cf1bf/joblib-0.14.1-py2.py3-none-any.whl
Collecting mujoco_py==<IP_ADDRESS>
  Using cached https://files.pythonhosted.org/packages/c3/a1/00f5482d6325565f35a81707b8c6b3e364bdc8f7b9487c15c18781e1432a/mujoco-py-<IP_ADDRESS>.tar.gz
  Installing build dependencies ... done
  WARNING: Missing build requirements in pyproject.toml for mujoco_py==<IP_ADDRESS> from https://files.pythonhosted.org/packages/c3/a1/00f5482d6325565f35a81707b8c6b3e364bdc8f7b9487c15c18781e1432a/mujoco-py-<IP_ADDRESS>.tar.gz#sha256=2a294006c66ed225c3409b9d60a91afeb7756f96fecf3d8c22116d00adf6d82a (from safety-gym==0.0.0).
  WARNING: The project does not specify a build backend, and pip cannot fall back to setuptools without 'wheel'.
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
    Preparing wheel metadata ... done
Collecting numpy~=1.17.4
  Using cached https://files.pythonhosted.org/packages/9e/cf/7cea38d32df6087d7c15bca8edef0be82e0d957119e9dafd7052dc6192f0/numpy-1.17.4-cp38-cp38-macosx_10_9_x86_64.whl
Collecting xmltodict~=0.12.0
  Using cached https://files.pythonhosted.org/packages/28/fd/30d5c1d3ac29ce229f6bdc40bbc20b28f716e8b363140c26eff19122d8a5/xmltodict-0.12.0-py2.py3-none-any.whl
Collecting scipy
  Using cached https://files.pythonhosted.org/packages/90/d2/44b70a930ad28da8f65d8c294ac88b20f561e5d650b85efea80381566db1/scipy-1.4.1-cp38-cp38-macosx_10_9_x86_64.whl
Requirement already satisfied: six in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from gym~=0.15.3->safety-gym==0.0.0) (1.13.0)
Collecting pyglet<=1.3.2,>=1.2.0
  Using cached https://files.pythonhosted.org/packages/1c/fc/dad5eaaab68f0c21e2f906a94ddb98175662cc5a654eee404d59554ce0fa/pyglet-1.3.2-py2.py3-none-any.whl
Collecting cloudpickle~=1.2.0
  Using cached https://files.pythonhosted.org/packages/c1/49/334e279caa3231255725c8e860fa93e72083567625573421db8875846c14/cloudpickle-1.2.2-py2.py3-none-any.whl
Collecting opencv-python
  Using cached https://files.pythonhosted.org/packages/c8/e8/bcef356c7f89433a5f4e631bbe898d03ba79d1c06a5d779829a10ddf16e8/opencv_python-<IP_ADDRESS>-cp38-cp38-macosx_10_9_x86_64.whl
Requirement already satisfied: imageio>=2.1.2 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (2.6.1)
Requirement already satisfied: Cython>=0.27.2 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (0.29.14)
Requirement already satisfied: glfw>=1.4.0 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (1.8.7)
Requirement already satisfied: cffi>=1.10 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (1.13.2)
Requirement already satisfied: fasteners~=0.15 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (0.15)
Collecting future
  Using cached https://files.pythonhosted.org/packages/45/0b/38b06fd9b92dc2b68d58b75f900e97884c45bedd2ff83203d933cf5851c9/future-0.18.2.tar.gz
Requirement already satisfied: pillow in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from imageio>=2.1.2->mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (6.2.1)
Requirement already satisfied: pycparser in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from cffi>=1.10->mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (2.19)
Requirement already satisfied: monotonic>=0.1 in /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages (from fasteners~=0.15->mujoco_py==<IP_ADDRESS>->safety-gym==0.0.0) (1.5)
Building wheels for collected packages: mujoco-py
  Building wheel for mujoco-py (PEP 517) ... error
  ERROR: Command errored out with exit status 1:
   command: /Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py build_wheel /var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/tmpv4_0jd48
       cwd: /private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py
  Complete output (49 lines):
  running bdist_wheel
  running build
  Removing old mujoco_py cext /private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/generated/cymj_<IP_ADDRESS>_38_macextensionbuilder_38.so
  Traceback (most recent call last):
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in <module>
      main()
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 181, in build_wheel
      return _build_backend().build_wheel(wheel_directory, config_settings,
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 208, in build_wheel
      return self._build_with_temp_dir(['bdist_wheel'], '.whl',
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 194, in _build_with_temp_dir
      self.run_setup()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 236, in run_setup
      super(_BuildMetaLegacyBackend,
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/build_meta.py", line 142, in run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 33, in <module>
      setup(
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/overlay/lib/python3.8/site-packages/setuptools/__init__.py", line 145, in setup
      return distutils.core.setup(**attrs)
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/dist.py", line 966, in run_commands
      self.run_command(cmd)
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/dist.py", line 985, in run_command
      cmd_obj.run()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-build-env-ie6xv95k/normal/lib/python3.8/site-packages/wheel/bdist_wheel.py", line 192, in run
      self.run_command('build')
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/cmd.py", line 313, in run_command
      self.distribution.run_command(command)
    File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/distutils/dist.py", line 985, in run_command
      cmd_obj.run()
    File "setup.py", line 29, in run
      import mujoco_py  # noqa: force build
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/__init__.py", line 3, in <module>
      from mujoco_py.builder import cymj, ignore_mujoco_warnings, functions, MujocoException
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 506, in <module>
      cymj = load_cython_ext(mujoco_path)
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 105, in load_cython_ext
      cext_so_path = builder.build()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 221, in build
      built_so_file_path = self._build_impl()
    File "/private/var/folders/gg/rh5zmb1x1zqfpsft1whnqwxr0000gn/T/pip-install-en8ndiu2/mujoco-py/mujoco_py/builder.py", line 324, in _build_impl
      raise RuntimeError(
  RuntimeError: Could not find GCC executable.

  HINT: On OS X, install GCC with `brew install gcc`. or `port install gcc`.
  ----------------------------------------
  ERROR: Failed building wheel for mujoco-py
  Running setup.py clean for mujoco-py
Failed to build mujoco-py
ERROR: Could not build wheels for mujoco-py which use PEP 517 and cannot be installed directly

Have you tried following the steps on: https://github.com/openai/mujoco-py?

I installed version 9 of gcc, it seems to work with the current pip for mujoco-py:
brew install gcc@9


⚠ Bofrost.com has degraded performance

In 3ebdaba, Bofrost.com (https://www.bofrost.com) experienced degraded performance:

HTTP code: 200
Response time: 1451 ms

Resolved: Bofrost.com performance has improved in 56a6f89 after 6 minutes.


    Fix grammatical errors and introduce app.component() in introduction.…

New updates on head repo.
https://github.com/vuejs/docs/commit/dfd86d3cf8080d25f32f72e406fa6f1723e1d406

resolved with 8204cb77c5d2d13cd6f46c4868104fbaf6c89fd9


Cleanup to schedulers

We redefine schedulers to work at the epoch level. This seems to be standard practice with a few exceptions.

the inverse-square-root scheduler with warmup is now made to work at the epoch level. We also eliminate an unreachable condition, ensure the lambda-coefficient is never zero, rename flags etc.
the linear decay scheduler, which we basically haven't used and didn't include in any of our hyperparameter work, is removed.

Note that the LightningCLI migration will make it possible for users to use basically any scheduler in PyTorch, Lightning, or specified by the user, so this is a temporary simplification to enable that migration.
Closes #243.

We redefine schedulers to work at the epoch level. This seems to be standard practice with a few exceptions.

Can you support this? I thought warmup was standard and is always done by number of steps, no?

I would not say that this is a well-established principle that one has to do it one way or the other. The Wu paper is somewhat unique in that they talk in steps and not epochs, not just for the scheduler but also use a "max_steps" rather than "max_epochs". Certainly they're not the only people to do that but it's uncommon, I think.

Did you run a test to train a transformer with warmup at the epoch level?

I have and it works great.

I usually use 4k steps for inflection from the Shije Wu transformer for character seq2seq tasks paper. Unsure how this actually translates to epochs since you'd be making fewer updates for the same number of steps. Do you have a suggestion or reference for how we should think of the warmup_epochs hyperparameter?

I think I'd just take 4k and divide by the number of batches per epoch; so if there are 400 batches per epoch then you'd set --warmup_epochs 10. I am using W&B to eyeball this and hoping to see it hit the warmup.
Supporting both step and epoch-based schedulers requires some way to indicate whether it's a step or epoch-based scheduler, and this isn't pretty. It is near impossible, as far as I can tell, in Lightning; it actually just has special casing that a certain scheduler is step-based and assumes all others are epoch-based. We are sort of overriding that now but it requires us to basically register every option in every scheduler we support as a flag.
The vision in LightningCLI is that all this configuration stuff lives in configuration files, not duplicated messily in the base model. But it doesn't have any way to know whether a scheduler is step- or epoch-based because PyTorch doesn't record that kind of information about its schedulers, and some schedulers are imaginable either step- or epoch-based. (However others only make sense as epoch-based. What I assert is that all of them can be made epoch-based.)
What do you think?

Hey Kyle, I had written a long response to this last week and I do not see it anywhere. Let's see if I can remember:

We redefine schedulers to work at the epoch level. This seems to be standard practice with a few exceptions.

Can you support this? I thought warmup was standard and is always done by number of steps, no?

I would not say that this is a well-established principle that one has to do it one way or the other. The Wu paper is somewhat unique in that they talk in steps and not epochs, not just for the scheduler but also use a "max_steps" rather than "max_epochs". Certainly they're not the only people to do that but it's uncommon, I think.

I am not sure it is unique in that way---they got that stuff from the attention is all you need paper, and generally as datasets get bigger I think most discussion is in terms of steps rather than epochs. to me: how many gradient updates did I make? seems more important than: how many times did I see all of the data? Of course, idk that this means schedulers need to be directed this way---I have never experimented much here---I am just making the point that I think configuring things wrt steps rather than epochs seems more natural for most use-cases and reproducibility to me.

Did you run a test to train a transformer with warmup at the epoch level?

I have and it works great.

I usually use 4k steps for inflection from the Shije Wu transformer for character seq2seq tasks paper. Unsure how this actually translates to epochs since you'd be making fewer updates for the same number of steps. Do you have a suggestion or reference for how we should think of the warmup_epochs hyperparameter?

I think I'd just take 4k and divide by the number of batches per epoch; so if there are 400 batches per epoch then you'd set --warmup_epochs 10. I am using W&B to eyeball this and hoping to see it hit the warmup.
Supporting both step and epoch-based schedulers requires some way to indicate whether it's a step or epoch-based scheduler, and this isn't pretty. It is near impossible, as far as I can tell, in Lightning; it actually just has special casing that a certain scheduler is step-based and assumes all others are epoch-based. We are sort of overriding that now but it requires us to basically register every option in every scheduler we support as a flag.

Not sure why its impossible---this should be configurable no? Though maybe we need some conditions in a child class of the actual torch scheduler? Either way, it is messy so it seems fine to remove for a bit while we update things that will enable this more cleanly if I understand correctly.

The vision in LightningCLI is that all this configuration stuff lives in configuration files, not duplicated messily in the base model. But it doesn't have any way to know whether a scheduler is step- or epoch-based because PyTorch doesn't record that kind of information about its schedulers, and some schedulers are imaginable either step- or epoch-based. (However others only make sense as epoch-based. What I assert is that all of them can be made epoch-based.)
What do you think?

mechanically, all of them can be epoch based without raising an error sure, but im not sure you can reproduce the exact optimization of a step based scheduler if you do not update the scheduler per-step... I suppose we can default it to work this way, and write a not eon how to override things in python to make your scheduler step-based if you choose?

I am not sure it is unique in that way---they got that stuff from the attention is all you need paper, and generally as datasets get bigger I think most discussion is in terms of steps rather than epochs. to me: how many gradient updates did I make? seems more important than: how many times did I see all of the data? Of course, idk that this means schedulers need to be directed this way---I have never experimented much here---I am just making the point that I think configuring things wrt steps rather than epochs seems more natural for most use-cases and reproducibility to me.

Not exactly since a step may be less than a gradient update (in fact often is in my settings).
Do you know of any other scheduler you'd like to support that is (necessarily, usually, always) step-based?
Lightning treats epoch-based as the default. It seems to me before the transformers paper, people either used no scheduler or they reduced on plateau (which is going to inherently be epoch-based). After this paper at least some people working with transformers use warmup. The paper defines this in terms of steps but it is not hard to redefine in terms of epochs, and other than the loss of precision it's not obvious you lose anything from doing so.

Not sure why its impossible---this should be configurable no? Though maybe we need some conditions in a child class of the actual torch scheduler? Either way, it is messy so it seems fine to remove for a bit while we update things that will enable this more cleanly if I understand correctly.

There are three logical possibilities, as I see it:

a scheduler is indifferent and we can interpret "step" either to be a batch or an epoch; we just need to pass "which". Sadly this is a pretty big lift in LightningCLI. The way I'd do it is to subclass every scheduler and put a place to put this information. I then need to override "configure_optimizers" to use this information (in LightningCLI you otherwise don't need to override this).
a scheduler only works in epoch mode; this is the case for reduce-on-plateau; I am not sure how this should interact with (1); does the scheduler have a slot for the metadata but it throws a configuration-time error?
ditto but the scheduler only works in step mode; I don't know if this exists but it poses the same issues as (2) if so.

Thoughts on this alternative design? This would be for the future.
I could also make separate subclasses for (1) and then tag them (i.e., add a property) as to whether they're epoch- or step-based.

mechanically, all of them can be epoch based without raising an error sure, but im not sure you can reproduce the exact optimization of a step based scheduler if you do not update the scheduler per-step... I suppose we can default it to work this way, and write a not eon how to override things in python to make your scheduler step-based if you choose?

It's true you can't run 3500 steps of warmup if the batches don't divide that way but I actually think working this way is uncommon. Maybe I'm wrong.
I appreciate the discussion here---it's helpful. I think I may want to push this through at the last minute before I do the CLI migration (for which I am waiting for you and Travis to close the other PRs), and we can consider my more elaborate design at a later date.

I am not sure it is unique in that way---they got that stuff from the attention is all you need paper, and generally as datasets get bigger I think most discussion is in terms of steps rather than epochs. to me: how many gradient updates did I make? seems more important than: how many times did I see all of the data? Of course, idk that this means schedulers need to be directed this way---I have never experimented much here---I am just making the point that I think configuring things wrt steps rather than epochs seems more natural for most use-cases and reproducibility to me.

Not exactly since a step may be less than a gradient update (in fact often is in my settings).

I assume you mean the case of gradient accumulation (don't know how else 1 step would not = one gradient update since to me thats the definition of a step)---and there I think that's an abuse of definition. In gradient accumulation we are redefining one step to include k forward passes before 1 gradient update in order to simulate a larger batch size. I think thats the only case where number of forward and backward passes differs no?

Do you know of any other scheduler you'd like to support that is (necessarily, usually, always) step-based?
Lightning treats epoch-based as the default. It seems to me before the transformers paper, people either used no scheduler or they reduced on plateau (which is going to inherently be epoch-based). After this paper at least some people working with transformers use warmup. The paper defines this in terms of steps but it is not hard to redefine in terms of epochs, and other than the loss of precision it's not obvious you lose anything from doing so.

Yeah and pytorch also seems to default to epoch, which I think is a good argument to do it that way.

Not sure why its impossible---this should be configurable no? Though maybe we need some conditions in a child class of the actual torch scheduler? Either way, it is messy so it seems fine to remove for a bit while we update things that will enable this more cleanly if I understand correctly.

There are three logical possibilities, as I see it:

a scheduler is indifferent and we can interpret "step" either to be a batch or an epoch; we just need to pass "which". Sadly this is a pretty big lift in LightningCLI. The way I'd do it is to subclass every scheduler and put a place to put this information. I then need to override "configure_optimizers" to use this information (in LightningCLI you otherwise don't need to override this).
a scheduler only works in epoch mode; this is the case for reduce-on-plateau; I am not sure how this should interact with (1); does the scheduler have a slot for the metadata but it throws a configuration-time error?
ditto but the scheduler only works in step mode; I don't know if this exists but it poses the same issues as (2) if so.

Thoughts on this alternative design? This would be for the future.

Right I see. This is similarly a good argument that we should default to just work in epoch mode (1).

I could also make separate subclasses for (1) and then tag them (i.e., add a property) as to whether they're epoch- or step-based.

mechanically, all of them can be epoch based without raising an error sure, but im not sure you can reproduce the exact optimization of a step based scheduler if you do not update the scheduler per-step... I suppose we can default it to work this way, and write a not eon how to override things in python to make your scheduler step-based if you choose?

It's true you can't run 3500 steps of warmup if the batches don't divide that way but I actually think working this way is uncommon. Maybe I'm wrong.

I don't follow. The fundamental difference I am describing, and the thing I don;t think that yoyodyne should be opinionated on (unless we need to be due to constraints in the libraries we use -- which it seems we do need this constraint for smooth support) is that if a scheduler is epoch-based, then the learning rate only changes once per epch, right?
So we make k gradient updates all with the same LR, where k is the number of steps in an epoch. For step-based, each of the k updates has a slightly different learning rate. This is an inherent difference which I believe you are saying does not matter much in your experiments. However, what I am saying is I would rather not make one of these impossible, since AFAIK step-based schedulers are common.
It seems to me that despite my argument here, the best course of action is to make your suggested update, which will make step-based learning-rate schedulers not possible out of box, but add a note somewhere about this, and suggesting where a developer should customize the code to write such a scheduler.

I appreciate the discussion here---it's helpful. I think I may want to push this through at the last minute before I do the CLI migration (for which I am waiting for you and Travis to close the other PRs), and we can consider my more elaborate design at a later date.

Sure. FYI #233 looks like its pasted into and updated in #247. I suggest we keep #233 open until #247 is merged, but we should not need both.

I do acknowledge the distinction between changing LR mid-epoch. I just don't see any reason to suppose it matters yet, which is why I am slightly nonchalant about this change.

I assume you mean the case of gradient accumulation (don't know how else 1 step would not = one gradient update since to me thats the definition of a step)---and there I think that's an abuse of definition. In gradient accumulation we are redefining one step to include k forward passes before 1 gradient update in order to simulate a larger batch size. I think thats the only case where number of forward and backward passes differs no?

That's what I meant, yeah.

Shall we discuss where to put a note acknowledging that we don;t support step-based scheduling and suggestions for how to write one? This doesn't have to go into this PR.

Just added some information of this form to the module docstring.
I wanted to draw your attention to one other late-breaking change here; I fixed some typing stuff for configure_optimizers and its helper methods.

Those notes and the typing changes LGTM.

I took this in a totally different direction: I now tag the supported schedulers with the config data they need so we can support step-based stuff. (I still maintain that the step/epochs distinction is not an important one here.) So nothing is lost, this is just cleanup that moves scheduler-specific logic from the base model to the schedulers.py module.
We can actually keep this up in LightningCLI if desired.
@Adamits please take one last look to see if you like this.

gentle ping on this @Adamits, I redesigned as described in previous comment.

This might be more appropriate for an email but while thinking about this, I was wondering if we could simplify the metric abstraction by porting the evaluator code into it, so that a metric both specifies how it should be used for logging AND the implementation for measuring that metric.
When you see metric.get_metric() it kind of sounds like it would implement the metric you want to measure, but in practice this is held by a completely different interface.
I can think about what this would require more, but do you see any problems with this?

No sounds good, take a stab at it sometime?


SubqueryAggregate does not expose parameters other than distinct

See https://github.com/martsberger/django-sql-utils/blob/88cf3a6ea513aacebd5bec616599938e77fd8e0a/sql_util/aggregates.py#L161-L168
This makes the ordering argument in ArrayAgg impossible to use. Ditto for any custom Aggregation a user may want to write

Somewhat related to django/django#28296

Ordering was added, but it is true that if there are other  parameters to the aggregation, there is no mechanism to pass them. I will look into making this more general.

The new default attribute on Sum would be lovely.