Installing pip dependencies: Failed

🐛 Bug

CondaEnvException: Pip failed
I have mamba and conda installed on my system but when i create the environment using mamba the following error occurs.
Steps to reproduce the behavior:
mamba env create -n home-robot -f src/home_robot/environment.yml
Additional context
(Log of the error)
Downloading and Extracting Packages
Preparing transaction: done
Verifying transaction: done
Executing transaction: done
Installing pip dependencies: / Ran pip subprocess with arguments:
['/home/deepbot/miniforge3/envs/home-robot/bin/python', '-m', 'pip', 'install', '-U', '-r', '/home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt', '--exists-action=b']
Pip subprocess output:
Collecting git+https://github.com/openai/CLIP.git (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 26))
Cloning https://github.com/openai/CLIP.git to /tmp/pip-req-build-b04bnx8p
Resolved https://github.com/openai/CLIP.git to commit a1d071733d7111c9c014f024669f959182114e33
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Collecting numpy<1.24 (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 1))
Using cached numpy-1.23.5-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.1 MB)
Requirement already satisfied: scipy in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 2)) (1.11.4)
Collecting sophuspy (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 3))
Using cached sophuspy-0.0.8-cp39-cp39-linux_x86_64.whl
Collecting pybullet (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 4))
Using cached pybullet-3.2.6-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (1.8 kB)
Collecting trimesh (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 5))
Using cached trimesh-4.0.8-py3-none-any.whl.metadata (18 kB)
Collecting pytest (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 6))
Using cached pytest-7.4.4-py3-none-any.whl.metadata (7.9 kB)
Collecting scikit-image (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 7))
Using cached scikit_image-0.22.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (13 kB)
Collecting scikit-fmm (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 8))
Using cached scikit_fmm-2023.4.2-cp39-cp39-linux_x86_64.whl
Requirement already satisfied: scikit-learn in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 9)) (1.3.2)
Collecting numpy-quaternion (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 10))
Using cached numpy_quaternion-2023.0.2-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (14 kB)
Collecting natsort (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 11))
Using cached natsort-8.4.0-py3-none-any.whl.metadata (21 kB)
Collecting frozendict (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 12))
Using cached frozendict-2.4.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (23 kB)
Collecting opencv-python (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 13))
Using cached opencv_python-<IP_ADDRESS>-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (20 kB)
Collecting pin>=2.6.17 (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached pin-2.6.21-1-cp39-cp39-manylinux_2_28_x86_64.whl.metadata (20 kB)
Collecting openai-clip (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 15))
Using cached openai_clip-1.0.1-py3-none-any.whl
Collecting timm (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 16))
Using cached timm-0.9.12-py3-none-any.whl.metadata (60 kB)
Collecting pandas (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 17))
Using cached pandas-2.1.4-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (18 kB)
Collecting mss (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 18))
Using cached mss-9.0.1-py3-none-any.whl (22 kB)
Collecting matplotlib (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19))
Using cached matplotlib-3.8.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.8 kB)
Collecting click (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 20))
Using cached click-8.1.7-py3-none-any.whl.metadata (3.0 kB)
Requirement already satisfied: yacs in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 21)) (0.1.8)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 22))
Using cached h5py-3.10.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.5 kB)
Collecting imageio (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 23))
Using cached imageio-2.33.1-py3-none-any.whl.metadata (4.9 kB)
Collecting pygifsicle (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 24))
Using cached pygifsicle-1.0.7-py3-none-any.whl
Collecting pynput (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 25))
Using cached pynput-1.7.6-py2.py3-none-any.whl (89 kB)
Collecting open3d (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached open3d-0.18.0-cp39-cp39-manylinux_2_27_x86_64.whl.metadata (4.2 kB)
Requirement already satisfied: pybind11 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from sophuspy->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 3)) (2.11.1)
Collecting iniconfig (from pytest->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 6))
Using cached iniconfig-2.0.0-py3-none-any.whl (5.9 kB)
Collecting packaging (from pytest->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 6))
Using cached packaging-23.2-py3-none-any.whl.metadata (3.2 kB)
Collecting pluggy<2.0,>=0.12 (from pytest->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 6))
Using cached pluggy-1.3.0-py3-none-any.whl.metadata (4.3 kB)
Collecting exceptiongroup>=1.0.0rc8 (from pytest->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 6))
Using cached exceptiongroup-1.2.0-py3-none-any.whl.metadata (6.6 kB)
Collecting tomli>=1.0.0 (from pytest->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 6))
Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
Collecting networkx>=2.8 (from scikit-image->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 7))
Using cached networkx-3.2.1-py3-none-any.whl.metadata (5.2 kB)
Requirement already satisfied: pillow>=9.0.1 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from scikit-image->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 7)) (9.4.0)
Collecting tifffile>=2022.8.12 (from scikit-image->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 7))
Using cached tifffile-2023.12.9-py3-none-any.whl.metadata (31 kB)
Collecting lazy_loader>=0.3 (from scikit-image->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 7))
Using cached lazy_loader-0.3-py3-none-any.whl.metadata (4.3 kB)
Requirement already satisfied: joblib>=1.1.1 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from scikit-learn->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 9)) (1.3.2)
Requirement already satisfied: threadpoolctl>=2.0.0 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from scikit-learn->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 9)) (3.2.0)
Collecting cmeel (from pin>=2.6.17->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached cmeel-0.53.3-py3-none-any.whl.metadata (5.1 kB)
Collecting cmeel-boost~=1.83.0 (from pin>=2.6.17->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached cmeel_boost-1.83.0-0-cp39-cp39-manylinux_2_28_x86_64.whl.metadata (1000 bytes)
Collecting cmeel-console-bridge<2,>=<IP_ADDRESS> (from pin>=2.6.17->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached cmeel_console_bridge-<IP_ADDRESS>-3-py3-none-manylinux_2_28_x86_64.whl.metadata (970 bytes)
Collecting cmeel-tinyxml<3,>=<IP_ADDRESS> (from pin>=2.6.17->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached cmeel_tinyxml-<IP_ADDRESS>-0-py3-none-manylinux_2_28_x86_64.whl.metadata (389 bytes)
Collecting cmeel-urdfdom<4,>=<IP_ADDRESS> (from pin>=2.6.17->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached cmeel_urdfdom-<IP_ADDRESS>-0-py3-none-manylinux_2_28_x86_64.whl.metadata (2.8 kB)
Collecting hpp-fcl<4,>=2.3.4 (from pin>=2.6.17->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 14))
Using cached hpp_fcl-2.4.0-0-cp39-cp39-manylinux_2_28_x86_64.whl.metadata (5.6 kB)
Collecting ftfy (from openai-clip->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 15))
Using cached ftfy-6.1.3-py3-none-any.whl.metadata (6.2 kB)
Collecting regex (from openai-clip->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 15))
Using cached regex-2023.12.25-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (40 kB)
Requirement already satisfied: tqdm in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from openai-clip->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 15)) (4.66.1)
Requirement already satisfied: torch>=1.7 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from timm->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 16)) (1.13.1)
Requirement already satisfied: torchvision in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from timm->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 16)) (0.14.1)
Requirement already satisfied: pyyaml in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from timm->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 16)) (6.0.1)
Collecting huggingface-hub (from timm->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 16))
Using cached huggingface_hub-0.20.2-py3-none-any.whl.metadata (12 kB)
Collecting safetensors (from timm->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 16))
Using cached safetensors-0.4.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.8 kB)
Collecting python-dateutil>=2.8.2 (from pandas->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 17))
Using cached python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
Collecting pytz>=2020.1 (from pandas->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 17))
Using cached pytz-2023.3.post1-py2.py3-none-any.whl.metadata (22 kB)
Collecting tzdata>=2022.1 (from pandas->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 17))
Using cached tzdata-2023.4-py2.py3-none-any.whl.metadata (1.4 kB)
Collecting contourpy>=1.0.1 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19))
Using cached contourpy-1.2.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.8 kB)
Collecting cycler>=0.10 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19))
Using cached cycler-0.12.1-py3-none-any.whl.metadata (3.8 kB)
Collecting fonttools>=4.22.0 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19))
Using cached fonttools-4.47.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (157 kB)
Collecting kiwisolver>=1.3.1 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19))
Using cached kiwisolver-1.4.5-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl.metadata (6.4 kB)
Requirement already satisfied: pyparsing>=2.3.1 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19)) (3.1.1)
Collecting importlib-resources>=3.2.0 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 19))
Using cached importlib_resources-6.1.1-py3-none-any.whl.metadata (4.1 kB)
Collecting support-developer>=1.0.5 (from pygifsicle->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 24))
Using cached support_developer-1.0.5-py3-none-any.whl
Collecting six (from pynput->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 25))
Using cached six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting evdev>=1.3 (from pynput->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 25))
Using cached evdev-1.6.1-cp39-cp39-linux_x86_64.whl
Collecting python-xlib>=0.17 (from pynput->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 25))
Using cached python_xlib-0.33-py2.py3-none-any.whl (182 kB)
Collecting dash>=2.6.0 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached dash-2.14.2-py3-none-any.whl.metadata (11 kB)
Collecting werkzeug>=2.2.3 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached werkzeug-3.0.1-py3-none-any.whl.metadata (4.1 kB)
Collecting nbformat>=5.7.0 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached nbformat-5.9.2-py3-none-any.whl.metadata (3.4 kB)
Collecting configargparse (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached ConfigArgParse-1.7-py3-none-any.whl.metadata (23 kB)
Collecting ipywidgets>=8.0.4 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached ipywidgets-8.1.1-py3-none-any.whl.metadata (2.4 kB)
Collecting addict (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached addict-2.4.0-py3-none-any.whl (3.8 kB)
Collecting pyquaternion (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached pyquaternion-0.9.9-py3-none-any.whl (14 kB)
INFO: pip is looking at multiple versions of cmeel-boost to determine which version is compatible with other requirements. This could take a while.
Collecting open3d (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached open3d-0.17.0-cp39-cp39-manylinux_2_27_x86_64.whl (420.5 MB)
Collecting nbformat==5.7.0 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached nbformat-5.7.0-py3-none-any.whl (77 kB)
Collecting fastjsonschema (from nbformat==5.7.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached fastjsonschema-2.19.1-py3-none-any.whl.metadata (2.1 kB)
Collecting jsonschema>=2.6 (from nbformat==5.7.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jsonschema-4.20.0-py3-none-any.whl.metadata (8.1 kB)
Collecting jupyter-core (from nbformat==5.7.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyter_core-5.7.1-py3-none-any.whl.metadata (3.4 kB)
Collecting traitlets>=5.1 (from nbformat==5.7.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached traitlets-5.14.1-py3-none-any.whl.metadata (10 kB)
Collecting open3d (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached open3d-0.16.0-cp39-cp39-manylinux_2_27_x86_64.whl (422.5 MB)
Collecting nbformat==5.5.0 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached nbformat-5.5.0-py3-none-any.whl (75 kB)
Collecting open3d (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached open3d-0.15.2-cp39-cp39-manylinux_2_27_x86_64.whl (408.7 MB)
Requirement already satisfied: setuptools>=40.8.0 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27)) (69.0.3)
Requirement already satisfied: wheel>=0.36.0 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27)) (0.42.0)
Collecting pygments>=2.7.4 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached pygments-2.17.2-py3-none-any.whl.metadata (2.6 kB)
Collecting jupyter-packaging~=0.10 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyter_packaging-0.12.3-py3-none-any.whl (15 kB)
Collecting jupyterlab==3.,>=3.0.0 (from open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyterlab-3.6.6-py3-none-any.whl.metadata (12 kB)
Collecting ipython (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached ipython-8.18.1-py3-none-any.whl.metadata (6.0 kB)
Collecting tornado>=6.1.0 (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached tornado-6.4-cp38-abi3-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.5 kB)
Collecting jupyterlab-server~=2.19 (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyterlab_server-2.25.2-py3-none-any.whl.metadata (5.9 kB)
Collecting jupyter-server<3,>=1.16.0 (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyter_server-2.12.3-py3-none-any.whl.metadata (8.4 kB)
Collecting jupyter-ydoc~=0.2.4 (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyter_ydoc-0.2.5-py3-none-any.whl.metadata (2.2 kB)
Collecting jupyter-server-ydoc~=0.8.0 (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached jupyter_server_ydoc-0.8.0-py3-none-any.whl (11 kB)
Collecting nbclassic (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached nbclassic-1.0.0-py3-none-any.whl (10.0 MB)
Collecting notebook<7 (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached notebook-6.5.6-py3-none-any.whl.metadata (2.5 kB)
Requirement already satisfied: jinja2>=2.1 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from jupyterlab==3.,>=3.0.0->open3d->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27)) (3.1.2)
Collecting open3d (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 27))
Using cached open3d-0.14.1-cp39-cp39-manylinux_2_27_x86_64.whl (395.6 MB)
Collecting imageio (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 23))
Using cached imageio-2.33.0-py3-none-any.whl.metadata (4.9 kB)
INFO: pip is still looking at multiple versions of cmeel-boost to determine which version is compatible with other requirements. This could take a while.
Using cached imageio-2.32.0-py3-none-any.whl.metadata (4.9 kB)
INFO: This is taking longer than usual. You might need to provide the dependency resolver with stricter constraints to reduce runtime. See https://pip.pypa.io/warnings/backtracking for guidance. If you want to abort this run, press Ctrl + C.
Using cached imageio-2.31.6-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.5-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.4-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.3-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.2-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.31.1-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.31.0-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.30.0-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.29.0-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.28.1-py3-none-any.whl (3.4 MB)
Using cached imageio-2.28.0-py3-none-any.whl (3.4 MB)
Using cached imageio-2.27.0-py3-none-any.whl (3.4 MB)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 22))
Using cached h5py-3.9.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.5 kB)
Using cached h5py-3.8.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.7 MB)
Using cached h5py-3.7.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.6.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.5.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.4.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.3.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.2.1-cp39-cp39-manylinux1_x86_64.whl (4.5 MB)
Using cached h5py-3.2.0-cp39-cp39-manylinux1_x86_64.whl (4.5 MB)
Using cached h5py-3.1.0-cp39-cp39-manylinux1_x86_64.whl (4.4 MB)
Using cached h5py-3.0.0-cp39-cp39-manylinux1_x86_64.whl (4.4 MB)
Collecting cached-property (from h5py->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 22))
Using cached cached_property-1.5.2-py2.py3-none-any.whl (7.6 kB)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 22))
Using cached h5py-2.10.0.tar.gz (301 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.9.0.tar.gz (287 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.8.0.tar.gz (274 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.7.1.tar.gz (264 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.7.0.tar.gz (256 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.6.0.tar.gz (245 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.5.0.tar.gz (684 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Collecting Cython>=0.17 (from h5py->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 22))
Using cached Cython-3.0.8-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.2 kB)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.okgy6y9s.requirements.txt (line 22))
Using cached h5py-2.4.0.tar.gz (172 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'error'
Pip subprocess error:
Running command git clone --filter=blob:none --quiet https://github.com/openai/CLIP.git /tmp/pip-req-build-b04bnx8p
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [6 lines of output]
Traceback (most recent call last):
File "", line 2, in
File "", line 34, in
File "/tmp/pip-install-zoyn90re/h5py_bd1b121e0db04141bc28cfead6694682/setup.py", line 24, in
from distutils.command.build_py
ImportError: cannot import name 'build_py_2to3' from 'distutils.command.build_py' (/home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages/setuptools/_distutils/command/build_py.py)
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
failed
CondaEnvException: Pip failed
Can you kindly tell me what is wrong?

This is definitely a version issue, it looks like openai clip is what's failing? if you comment that out from the environment does everything else work?

It's also using the wrong version of h5py

This is definitely a version issue, it looks like openai clip is what's failing? if you comment that out from the environment does everything else work?

No even after commenting out that line I still have import error.
ImportError: cannot import name 'build_py_2to3' from 'distutils.command.build_py' (/home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages/setuptools/_distutils/command/build_py.py)
[end of output]
And when I activate the  created environment (home-robot)
pip install openai-clip works fine.
Reference: https://github.com/openai/whisper/discussions/1645

It's also using the wrong version of h5py

I tried to fix the import error ImportError: cannot import name 'build_py_2to3' from 'distutils.command.build_py' by manually installing setuptools<=57.5.0 in the environment.
Reference : https://stackoverflow.com/questions/75085575/importerror-cannot-import-name-build-py-2to3-from-distutils-command-build-py
But after that open3d and matplotlib can't be resolved together. Here is a snip from the error log.
Collecting open3d (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 26))
Using cached open3d-0.14.1-cp39-cp39-manylinux_2_27_x86_64.whl (395.6 MB)
Collecting imageio (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 23))
Using cached imageio-2.33.0-py3-none-any.whl.metadata (4.9 kB)
INFO: pip is still looking at multiple versions of cmeel-boost to determine which version is compatible with other requirements. This could take a while.
Using cached imageio-2.32.0-py3-none-any.whl.metadata (4.9 kB)
INFO: This is taking longer than usual. You might need to provide the dependency resolver with stricter constraints to reduce runtime. See https://pip.pypa.io/warnings/backtracking for guidance. If you want to abort this run, press Ctrl + C.
Using cached imageio-2.31.6-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.5-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.4-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.3-py3-none-any.whl.metadata (4.6 kB)
Using cached imageio-2.31.2-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.31.1-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.31.0-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.30.0-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.29.0-py3-none-any.whl.metadata (4.7 kB)
Using cached imageio-2.28.1-py3-none-any.whl (3.4 MB)
Using cached imageio-2.28.0-py3-none-any.whl (3.4 MB)
Using cached imageio-2.27.0-py3-none-any.whl (3.4 MB)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 22))
Using cached h5py-3.9.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.5 kB)
Using cached h5py-3.8.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.7 MB)
Using cached h5py-3.7.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.6.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.5.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.4.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.3.0-cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (4.5 MB)
Using cached h5py-3.2.1-cp39-cp39-manylinux1_x86_64.whl (4.5 MB)
Using cached h5py-3.2.0-cp39-cp39-manylinux1_x86_64.whl (4.5 MB)
Using cached h5py-3.1.0-cp39-cp39-manylinux1_x86_64.whl (4.4 MB)
Using cached h5py-3.0.0-cp39-cp39-manylinux1_x86_64.whl (4.4 MB)
Collecting cached-property (from h5py->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 22))
Using cached cached_property-1.5.2-py2.py3-none-any.whl (7.6 kB)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 22))
Using cached h5py-2.10.0.tar.gz (301 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.9.0.tar.gz (287 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.8.0.tar.gz (274 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.7.1.tar.gz (264 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.7.0.tar.gz (256 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.6.0.tar.gz (245 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.5.0.tar.gz (684 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Collecting Cython>=0.17 (from h5py->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 22))
Using cached Cython-3.0.8-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.2 kB)
Collecting h5py (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 22))
Using cached h5py-2.4.0.tar.gz (172 kB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached h5py-2.3.1.tar.gz (1.1 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Collecting matplotlib (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 19))
Using cached matplotlib-3.8.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.8 kB)
Using cached matplotlib-3.8.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.8 kB)
Using cached matplotlib-3.8.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.8 kB)
Using cached matplotlib-3.7.4-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.7 kB)
Using cached matplotlib-3.7.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.7 kB)
Using cached matplotlib-3.7.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.6 kB)
Collecting pyparsing<3.1,>=2.3.1 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 19))
Using cached pyparsing-3.0.9-py3-none-any.whl (98 kB)
Collecting matplotlib (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 19))
Using cached matplotlib-3.7.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.6 MB)
Using cached matplotlib-3.7.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.6 MB)
Using cached matplotlib-3.6.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.8 MB)
Using cached matplotlib-3.6.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.8 MB)
Using cached matplotlib-3.6.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.8 MB)
Using cached matplotlib-3.6.0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.8 MB)
Using cached matplotlib-3.5.3-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.whl (11.2 MB)
Using cached matplotlib-3.5.2-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.whl (11.2 MB)
Using cached matplotlib-3.5.1-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.whl (11.2 MB)
Using cached matplotlib-3.5.0-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.whl (11.2 MB)
Collecting setuptools-scm>=4 (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 19))
Using cached setuptools_scm-8.0.4-py3-none-any.whl.metadata (6.4 kB)
Collecting matplotlib (from -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 19))
Using cached matplotlib-3.4.3-cp39-cp39-manylinux1_x86_64.whl (10.3 MB)
Using cached matplotlib-3.4.2-cp39-cp39-manylinux1_x86_64.whl (10.3 MB)
Using cached matplotlib-3.4.1-cp39-cp39-manylinux1_x86_64.whl (10.3 MB)
Using cached matplotlib-3.4.0-cp39-cp39-manylinux1_x86_64.whl (10.3 MB)
Using cached matplotlib-3.3.4-cp39-cp39-manylinux1_x86_64.whl (11.5 MB)
Using cached matplotlib-3.3.3-cp39-cp39-manylinux1_x86_64.whl (11.6 MB)
Using cached matplotlib-3.3.2.tar.gz (37.9 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Requirement already satisfied: certifi>=2020.06.20 in /home/deepbot/miniforge3/envs/home-robot/lib/python3.9/site-packages (from matplotlib->-r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 19)) (2023.11.17)
Using cached matplotlib-3.3.1.tar.gz (38.8 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.3.0.tar.gz (38.8 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.2.2.tar.gz (40.3 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.2.1.tar.gz (40.3 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.2.0.tar.gz (40.5 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.1.3.tar.gz (40.9 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.1.2.tar.gz (40.9 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.1.1.tar.gz (37.8 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.1.0.tar.gz (37.2 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.0.3.tar.gz (36.6 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.0.2.tar.gz (36.5 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.0.1.tar.gz (36.5 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-3.0.0.tar.gz (36.3 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Using cached matplotlib-2.2.5.tar.gz (36.7 MB)
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
INFO: pip is looking at multiple versions of open3d to determine which version is compatible with other requirements. This could take a while.
INFO: pip is still looking at multiple versions of open3d to determine which version is compatible with other requirements. This could take a while.
The conflict is caused by:
The user requested matplotlib
open3d 0.18.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.18.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.18.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.17.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.18.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.16.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.18.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.15.2 depends on matplotlib>=3
The user requested matplotlib
open3d 0.18.0 depends on matplotlib>=3
The user requested matplotlib
open3d 0.14.1 depends on matplotlib>=3
To fix this you could try to:

loosen the range of package versions you've specified
remove package versions to allow pip attempt to solve the dependency conflict

Pip subprocess error:
ERROR: Cannot install -r /home/deepbot/habitat/homorobottest/home-robot/src/home_robot/condaenv.cuh9ey21.requirements.txt (line 26), matplotlib and open3d==0.18.0 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
failed
CondaEnvException: Pip failed

@cpaxton Another thing I noticed in the environmen.yml file that numpy <1.24 is specified along with pin>=2.6.17.
While manually installing pin and numpy , I saw that pin>=2.6.17 needs numpy>1.26.

Looking into this. I think some of our unfixed packages keep causing errors every time i fix this

@vaibhavoutat maybe this is because of Mamba, but when i do this i see:
(base) cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ conda activate tmp03
(tmp03) cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ pip show numpy
Name: numpy
Version: 1.23.5
Summary: NumPy is the fundamental package for array computing with Python.
Home-page: https://www.numpy.org
Author: Travis E. Oliphant et al.
Author-email:
License: BSD
Location: /home/cpaxton/miniconda3/envs/home_robot/envs/tmp03/lib/python3.9/site-packages
Requires:
Required-by: cmeel-boost, contourpy, fvcore, h5py, imageio, matplotlib, numpy-quaternion, open3d, opencv-python, pandas, pyquaternion, scikit-fmm, scikit-image, scikit-learn, SciPy, sophuspy, tifffile, torch_geometric, torchvision, trimesh
(tmp03) cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ mamba env create -n tmp03 -f src/home_robot/environment.yml ^C
(tmp03) 130 cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ pip show pin
Name: pin
Version: 2.6.20
Summary: A fast and flexible implementation of Rigid Body Dynamics algorithms and their analytical derivatives
Home-page: https://github.com/stack-of-tasks/pinocchio
Author:
Author-email:
License:
Location: /home/cpaxton/miniconda3/envs/home_robot/envs/tmp03/lib/python3.9/site-packages
Requires: cmeel, cmeel-boost, cmeel-console-bridge, cmeel-tinyxml, cmeel-urdfdom, hpp-fcl
Required-by:

And it works fine

Environment created with
mamba env create -n tmp03 -f src/home_robot/environment.yml

can you share what  you ran?

maybe my enviromment is messy somehow

Environment created with
mamba env create -n tmp03 -f src/home_robot/environment.yml

I also created the environmnet with this command.
mamba env create -n home-robot -f src/home_robot/environment.yml

@vaibhavoutat maybe this is because of Mamba, but when i do this i see:
(base) cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ conda activate tmp03
(tmp03) cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ pip show numpy
Name: numpy
Version: 1.23.5
Summary: NumPy is the fundamental package for array computing with Python.
Home-page: https://www.numpy.org
Author: Travis E. Oliphant et al.
Author-email:
License: BSD
Location: /home/cpaxton/miniconda3/envs/home_robot/envs/tmp03/lib/python3.9/site-packages
Requires:
Required-by: cmeel-boost, contourpy, fvcore, h5py, imageio, matplotlib, numpy-quaternion, open3d, opencv-python, pandas, pyquaternion, scikit-fmm, scikit-image, scikit-learn, SciPy, sophuspy, tifffile, torch_geometric, torchvision, trimesh
(tmp03) cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ mamba env create -n tmp03 -f src/home_robot/environment.yml ^C
(tmp03) 130 cpaxton@cpaxton-ThinkStation-P620:~/src/home-robot$ pip show pin
Name: pin
Version: 2.6.20
Summary: A fast and flexible implementation of Rigid Body Dynamics algorithms and their analytical derivatives
Home-page: https://github.com/stack-of-tasks/pinocchio
Author:
Author-email:
License:
Location: /home/cpaxton/miniconda3/envs/home_robot/envs/tmp03/lib/python3.9/site-packages
Requires: cmeel, cmeel-boost, cmeel-console-bridge, cmeel-tinyxml, cmeel-urdfdom, hpp-fcl
Required-by:

And it works fine

Well I did the installation manually for all the pip dependencies and followed all the instructions ahead , somehow my numpy also shows as Version: 1.23.5 with correct pin too. Maybe it got fixed will following the further details , but I can't still make the
mamba env create -n tmp03 -f src/home_robot/environment.yml
command to work without errors.  Same that I posted originally.

So I believe this is an issue with setuptools/distutils: https://stackoverflow.com/questions/75085575/importerror-cannot-import-name-build-py-2to3-from-distutils-command-build-py
Can you share your versions of these? Maybe we need to pin a specific version to make this work better @vaibhavoutat

Hey sorry for following up late , but I found out that when I install the dependencies using ovmm-challenge as suggested in the readme , it is then when I get this error, and when i use the master branch then I don't run up into the errors.
This gives error: Important note for new OVMM challenge participants: If you are participating in the challenge and starting now, please use the home-robot release home-robot-ovmm-challenge-2023-v0.1.2. You can start out by cloning home-robot via: git clone https://github.com/facebookresearch/home-robot --branch home-robot-ovmm-challenge-2023-v0.1.2
On the other hand the main branch works fine: git clone https://github.com/facebookresearch/home-robot.git
So maybe it's the difference between these files.

@cpaxton Can you please have a look.

Hey sorry for following up late , but I found out that when I install the dependencies using ovmm-challenge as suggested in the readme , it is then when I get this error, and when i use the master branch then I don't run up into the errors.
This gives error: Important note for new OVMM challenge participants: If you are participating in the challenge and starting now, please use the home-robot release home-robot-ovmm-challenge-2023-v0.1.2. You can start out by cloning home-robot via: git clone https://github.com/facebookresearch/home-robot --branch home-robot-ovmm-challenge-2023-v0.1.2
On the other hand the main branch works fine: git clone https://github.com/facebookresearch/home-robot.git
So maybe it's the difference between these files.

@cpaxton Can you please have a look.

I see that pinocchio is missing in the dependencies and there are stricter constraints

Sorry can you switch to main? I need to change the instructions to not use the OVMM challenge branch any more; I'm not sure that's being maintained now that the challenge is over.

Sorry can you switch to main? I need to change the instructions to not use the OVMM challenge branch any more; I'm not sure that's being maintained now that the challenge is over.

Okay will do that. Thanks


Remove pin length restriction when Pin type is USER_DEFINED

User defined pin is empty if the User defined pin length is not the same as the pin length passed in to the generatePin(...) method.

Fixed on commit: 3934fa358de41c52634d0642159a6c10699df175


0.18.1 Fails to Release

Output
+ cargo release --version
cargo-release-release 0.18.1
[Pipeline] sh
+ cargo release -v --execute --skip-publish --no-verify --no-confirm patch

[2021-10-11T17:29:23Z DEBUG cargo_release] Files changed in LIB since LIB-0.2.0: [
        "/var/lib/jenkins/workspace/LIB_master/Cargo.toml",
        "/var/lib/jenkins/workspace/LIB_master/Jenkinsfile",
        "/var/lib/jenkins/workspace/LIB_master/src/lib.rs",
    ]
[2021-10-11T17:29:23Z DEBUG globset] glob converted to regex: Glob { glob: "**/*", re: "(?-u)^(?:/?|.*/)[^/]*$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true }, tokens: Tokens([RecursivePrefix, ZeroOrMore]) }
[2021-10-11T17:29:23Z DEBUG globset] built glob set; 0 literals, 1 basenames, 0 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 1 regexes
[2021-10-11T17:29:23Z INFO  cargo_release] Update LIB to version 0.2.1
[2021-10-11T17:29:23Z DEBUG cargo_release::replace] Substituting values for /var/lib/jenkins/workspace/LIB_master/Cargo.toml
[master ec10f3e] (cargo-release) {{crate_name}} version {{version}} [ci skip]
 1 file changed, 1 insertion(+), 1 deletion(-)
thread 'main' panicked at '`disable_` flags are deprecated and can't be set at the same time with their positive versions', /home/build/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-release-0.18.1/src/config.rs:512:31
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

release.toml
tag-name="{{crate_name}}-{{version}}"
dev-version=false
pre-release-commit-message="(cargo-release) {{crate_name}} version {{version}} [ci skip]"
tag-message="(cargo-release) {{crate_name}} version {{version}} [ci skip]"
post-release-commit-message="(cargo-release) Released {{crate_name}}-{{version}}, start next development iteration {{next_version}} [ci skip]"
pre-release-replacements = [
  {file="Cargo.toml", search="\\nversion\\s*=\\s*\"[a-z0-9\\.-]+\"", replace="\nversion = \"{{version}}\""},
]
consolidate-commits=true
consolidate-pushes=true

Drat, a release build where all the useful information has been removed.
Any word on additional configs being merged in?
I referred to this as a "should be impossible" bug, say you did
dev-version = false
no-dev-version = false

I'm not seeing two conflicting parameters though

Config has dev-version
Command line as skip-publish, no-verify

Next up is a bug where we accidentally merge two layers of the config together in a way to get a conflict.  Its designed to prevent that, so what could it be?
Hmm, looks like I found a spot that bypasses our invariant checks.  I'm going to go test that theory.  Can you post a Cargo.toml so if I produce a fix, I have good confidence it will help in your case?


Cross Domain Generated Visitor Transforms

This adds a feature to PIG which will generate a variant of VisitorTransform where the input domain and output domains are different.  This intended for use with permuted domains but this can be applied to any two domains.
The type universe definition has been extended to include:
(define <name, currently ignored>
    (transform <source-domain> <destination-domain>))

When such a clause is included in the type universe, the Kotlin target of PIG will also generate a <source-domain>.VisitorTransformTo<destination-domain> class, which is nearly identical to the previous generated VistiorTransform classes, except:

For every product and sum variant that is the same in both domains, the transform*() function is generated fully and is open.
All the transform*() functions accept types from the <source-domain> and return instances of <destination-domain>
The generated transform*() function is abstract if it does not exist or is has a different definition in <destination-domain>. (details omitted for the sake of brevity)

This PR is a draft because:

[ ] I still need to revise the syntax for declaring these transforms (they do not need a name, I think)
[ ] More tests are needed
[ ] The type domain names specified in the (transform <source-domain> <destination-domain>) need to be validated
[ ] All transform*() functions for elements of products and records are being skipped if any element is different on <destination-domain>, but they could still be generated for product and record elements if they have the same type and name, even if one the other elements is different.  The impact of this is that the derived visitors are probably a little more code than they truly need to be right now.
[ ] Update README.md with:

[ ] new grammar
[ ] description of cross-domain visitor transforms

However, the basic concept works--see pig-tests/test/org/partiql/pig/tests/VisitorTransformToAnotherDomainTests.kt
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

When I published https://github.com/partiql/partiql-ir-generator/pull/59 a few days ago I had entirely forgotten that I had published this PR back in September.  Since #59 includes a rebase against the most-up-to-date master, I am closing this PR.

When I published https://github.com/partiql/partiql-ir-generator/pull/59 a few days ago I had entirely forgotten that I had published this PR back in September.  Since #59 includes a rebase against the most-up-to-date master, I am closing this PR.


Max night issue

is there anything wrong?

""

VueHotelDatepicker :ref="datepickerId" :datepickerd="datepickerId" :selectForward="selectForward" :maxNights="maxNights" v-on:update="getDate($event)"
format="MM-DD-YYYY" :placeholder="placeholder"

Hi @depus9,
what's the package version you are using?
some attributes seems not supported (ie: datepickerId) at current version, please update package version for usage.


Firefox version

Extension looks great. Any plans for a Firefox WebExtension build?

Please see here: https://twitter.com/hkgnp/status/1590705591101849600


Google Login failed

DoesNotExist at /auth/complete/google-oauth2/
User matching query does not exist.

failed at this line in accounts/pipelines.py:
user = User.objects.get(username=details['username'])


Small update for sktime 0.6.2 -> 0.7.0

Fixes Linux part of #2495

Closing, work merged with #2492


reintroduce str as input to group_by in aggregate

This PR reintroduces using just string syntax when performing a aggregate group by query so that the happy path of usage is easier as it was previously, e.g.:
res = collection.aggregate.over_all(
    group_by="text",
    ...
)

instead of:
res = collection.aggregate.over_all(
    group_by=weaviate.classes.aggregate.GroupByAggregate(prop="text"),
    ...
)

Codecov Report
Attention: 277 lines in your changes are missing coverage. Please review.

Comparison is base (e977081) 93.48% compared to head (657ce0a) 95.50%.
Report is 41 commits behind head on main.

Files
Patch %
Lines

integration/test_collection_openai.py
41.25%
84 Missing :warning:

weaviate/collections/batch/base.py
83.87%
45 Missing :warning:

integration/test_collection_rerank.py
32.69%
35 Missing :warning:

integration/test_batch_v4.py
95.00%
14 Missing :warning:

integration_v3/test_backup_v4.py
92.76%
11 Missing :warning:

mock_tests/test_collection.py
85.71%
10 Missing :warning:

weaviate/collections/aggregations/base.py
94.57%
9 Missing :warning:

integration/test_collection.py
99.05%
8 Missing :warning:

weaviate/collections/batch/batch_wrapper.py
86.20%
8 Missing :warning:

integration/conftest.py
88.52%
7 Missing :warning:

... and 12 more

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #843      +/-   ##
==========================================
+ Coverage   93.48%   95.50%   +2.02%
==========================================
  Files          70      167      +97
  Lines        8625    17089    +8464
==========================================
+ Hits         8063    16321    +8258
- Misses        562      768     +206

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Colliding With Tiling Sprite doesn't work in 2.3.0

Seems like the collision with tiling sprites is broken in the latest version. An easy way to see this is via this example http://phaser.io/examples/v2/tile-sprites/colliding-with-tiling-sprite where the ball just passes the tileSprite. It works in 2.2.2.
Is there a workaround or should I stick to the old version in the meantime?

https://github.com/photonstorm/phaser/issues/1702


favicon with transparent regions not rendered on local serve

I have a favicon with a transparent background - it gets rendered appropriately in the website at my github site but not on localhost:80000
Here's a picture
https://imgur.com/d5DvzQf.png

This isn't related to Franklin but likely related to caching on your Browser possibly of a previous version of the favicon.
Could you try (1) opening the local one in another browser or (2) opening the local one in a incognito window on Firefox and check?
I'll close this for now as I'm pretty sure it's unrelated to Franklin (the fact that it works fine online shows this).


Examples documentation

Documentation clarification for example, examples

Does it make sense to allow a description property for the examples scenario?  If I have N different examples, I'm likely showing the different valid ways this request/response could be structured and it would be nice to have a description.  Yes, this would mean an object for the example instead of a string/object but it could be really useful.  Thoughts?

:shipit:

@whitlockjc - @darrelmiller brought the issue up during the call. While it makes sense, to avoid the extra layer we won't support it now. Maybe in future versions.
Other than that, LGTM.

:shipit:


Fix/data deletion

Closes #52
In progress.
Adds: Caching. Cache names are now simple key strings for faster fetches. The caches get collected by garbage collector.
The bottleneck seems not to be DB after tests. I am investigating this further.
Tests:
I think we can ignore the caching all together, the tests seem to show that DB fetches are quite fast, will look more.

It seems we are adding a bunch of binary files in the "files" directory. Please remove.
We can merge the other changes and test.

I was not able to locate the files directory, it was previously present in the examples directory which is no longer there. Could you please let me know where the files directory is? @tntech-ngin

Okay - merging.

@sankalpatimilsina12 @xai990 @GportDev Merged, please test.


to remove a bug in the ui theme div

Currently when the ui theme namely the scroll bars for brightness,hue and saturation are changed, only one side of the cube gets reflected with these chaned.It should reflect on all the sides of the cube. I wish to adress to this issue and fix this.
I agree to follow this project's Code of Conduct.
I'm a GSSoC'24 contributor.
I want to work on this issue.

I want to work on this project.Please assign it to me.


Newly made PGP keys are expired (K-9 & Openkeychain)

Expected behaviour
It should encrypt the message before sending
Actual behaviour
It tells me that the key is revoked or expired while checking it on the keyservers there is nothing wrong with the keys.
Steps to reproduce

Configure K-9 mail
Create a new key for above mail with Openkeychain, upload it to the servers
Get on another mailclient the pubkey and send a mail to the mailaccount signed and encrypted with the pubkey
Mail comes into K-9 mail and is saying "This message was signed by an expired key!"
Replying to that mail says "Send failed: Revoked/Expired key cannot be used for sign or encryption"

Environment
K-9 Mail version: 5.202
Android version: 7.1.1
Account type (IMAP, POP3, WebDAV/Exchange): IMAP
Whole story:
I have installed K-9 mail and Openkeychain to two of my Nexus devices. Both are using their own email address.
I have setup the mailaccounts on both of them and created for each of their own address a key in Openkeychain. They are all uploaded to 2 keyservers.
After that i have imported the key of the other Nexus device into the other one and vice versa. Both are confirmed.
So i setup an email op phone A and sign it with the public key of phone B. A nice green padlock appears behind my email address and the email address of phone B is green also. So i begin to type my email. When i push send i get the following error

Send failed: Revoked/Expired key cannot be used for sign or encryption

If i send an email from the phone B with the pub key of phone A, it shows me a green padlock next to the mail address of phone B, but an orange color of the  mail address of phone A. It send the email though, but when i look on phone A it says that

This message was signed by an expired key!

So, my guess is that phone A has a expired key or something. But it has been newly made by Openkeychain. What can i do to make it valid?

Both @dschuermann and me tried to reproduce this but failed. Can you tell me the key id of one of those keys? Or, if you just generated the secret keys for testing here, send them to me? -><EMAIL_ADDRESS>

Both keys are on the sks keyserver
5x (at) safe-mail.eu
6p (at) safe-mail.eu
5x has multiple keys on the server, but i know for sure i have the right key ID of it


check for sandbox SecurityErrors so snowplow clients can run in sandboxed environments

My use-case is that the client I work for is using a low-code rapid app development solution called Retool.
I have been building support apps with this to get around long-lasting tech debt and legacy issues, and, in all honesty:
it's pretty good! (even though it's not a long-term solution to any of those problems)
We want to track app usage and other things, however, Retool doesn't offer a tracking solution to our liking.
So we started implementing Snowplow using the javascript tracker.
This is possible, however, since Retool-built apps operate within a 'sandbox' mode (I have yet to figure out how this works - I expect CSP headers), session- and local Storage checks fail, due to javascript not being allowed to access anything on the window scope.
This causes the snowplow client to not want to even start, with the following error (visible from within Retool in the screenshot I will post in a reply)
startSnowplough: Failed to read the 'localStorage' property from 'Window': The document is sandboxed and lacks the 'allow-same-origin' flag.
I have made a very crude PR to what I think might be a solution to this problem, but it's pretty rough and probably there are better ways to do this.

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

I signed it! using a mid air hand gesture

Interesting! Thanks for the PR, we're a little busy to look at this in much depth over the next couple of weeks but I'll find time as soon as possible to dig into this.
There's quite a lot of functionality in the tracker that depends on the window object beyond localStorage however, such as various event handlers, are these fine in the sandbox?
Additionally, if it's just localStorage, could you try and set stateStorageStrategy: 'none' when initialising the tracker? We shouldn't check for window.localStorage then.
window.snowplow('newTracker', 'sp', '<<MY_COLLECTOR>>', {
  appId: 'my-app',
  stateStorageStrategy: 'none'
});

Side note: As a Brit, I very much enjoyed the renaming to plough 😉

@paulboocock I was already thinking of possible other functionality depending on window. after I made the PR 😬
I am not sure what is and what is not supported - still trying to figure out what this security sandbox actually entails, and how they enforce this.
I need Retool support to get back to me about that. Will update here when I know more
Yes! As a non-native speaker, whenever I think of writing 'plough' I apparently default to the British written form and not the American: somehow the latter doesn't sit right with me 🤔
I have tried both: stateStorageStrategy: 'none' and stateStorageStrategy: 'cookie' and somehow those still trigger the error messages. I did not yet reverse-engineer what actually happens when these are set, but I would also assume they would result in not doing these checks. let me retest this, maybe this was cache or some other issue at work.

With regards to stateStorageStrategy: 'none', this line means we check for localStorage before checking if we are allowed to use local storage, we should check useLocalStorage before calling localStorageAccessible(). Seems pointless to check it if we're not permitted by configuration to use it. I've opened https://github.com/snowplow/snowplow-javascript-tracker/issues/974 to track that.
https://github.com/snowplow/snowplow-javascript-tracker/blob/268f6cef26edb87b51fda39126fd7ffbc41dff5b/libraries/browser-tracker-core/src/tracker/out_queue.ts#L109
The logic of the try { } catch { } within hasLocalStorage() is also rather interesting in this part of the code base. We assume when it errors that this means the browser supports localStorage, as this is more for feature detection rather than availability of it. We wrap this in a localStorageAccessible() which then tries to write to it and if that fails then we don't use it.
What I find interesting about your error, I'd expect localStorageAccessible() to return false and I'd expect things to still work since this part of the code base is full of try-catch statements. The tracker should continue just without any local storage functionality but it seems like the script is killed or something(?) for trying to access localStorage.

Yes, exactly this is what is think is happening. I don't know if this is Retool specific (i.e. Retool has built their own security proxy system around this and then purposefully fails when it detects usage) which I would find hard to believe, or this is default (chrome) browser behaviour, which is a lot easier to assume (and in that case interesting for snowplough to try to cater for ;) )
Hmm... that said actually, I have not checked what happens when testing in other browsers, let me do this as well.
For me this is also new, just like the sandbox environment: usually whenever I'd had a need for using session or localStorage I would also check for existence and then if getting and setting an item works, just like is done in the tracker.

Okay, so Retool is using a sandboxed Iframe: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox. I've asked which restrictions are in place, I suspect at least allow-same-origin, which probably is the culprit 😬

Ah ok. I've knocked together a quick build and I'm wondering if this changes/fixes the error you get. Could you test this out for me? You'll need to use stateStorageStrategy: 'none'.
window.snowplow('newTracker', 'sp', '<<MY_COLLECTOR>>', {
  appId: 'my-app',
  stateStorageStrategy: 'none'
});

sp.zip

Okay thanks @paulboocock, much appreciated.
Let me figure out a way to host this somewhere in our domain (or not) and get back to you!

@michahell If you want to host it for testing, you could drop it into a new public Github repository and enable Github pages on that repository.

Retool support came back to me with this:
Hi again!
We looked into this further last night, it it looks like we use all of the sandbox restrictions by default (due to the empty string, which would be the options to remove).
// enumeration of all security restrictions
I chose for hosting the file on our client's bitbucket static hosting, will be up soon so I can test.

I have modified the tracker init script as follows:
;(function(p,l,o,w,i,n,g){if(!p[i]){p.GlobalSnowplowNamespace=p.GlobalSnowplowNamespace||[]; p.GlobalSnowplowNamespace.push(i);p[i]=function(){(p[i].q=p[i].q||[]).push(arguments) };p[i].q=p[i].q||[];n=l.createElement(o);g=l.getElementsByTagName(o)[0];n.async=1; n.src=w;g.parentNode.insertBefore(n,g)}}(window,document,"script","https://carepaydev.bitbucket.io/sp.js","snowplow"));

but when I try this in Retool, it still gives me the same warning @paulboocock

Can you send me the newTracker configuration object too? I'll see if I can reproduce to too then.

ah yes ofc, sorry 😬
This is the barebone tracker config I have right now (script triggered by a button: every Js has to be triggered by user action in Retool)
        const namespace = 'tracker_retool_apps';
        const collectorUrl = 'payer.ke-test.carepay.dev/api/snowplow';
        const title = 'retool app snowplough test';

        window.snowplow('newTracker', namespace, collectorUrl, {
          appId: 'retool_app_snowplough_test',
          anonymousTracking: { withServerAnonymisation: true },
          stateStorageStrategy: 'none',
          eventMethod: 'post',
          contexts: {
            webPage: true // default, can be omitted
          }
        });

        window.snowplow('enableActivityTracking', {
          minimumVisitLength: 30,
          heartbeatDelay: 10
        });

        window.snowplow('trackPageView', { title });

And this is what I have on the other button in Retool:
        console.log('window.snowplow: ', window.snowplow);

        window.snowplow('trackStructEvent', {
          category: 'Tests',
          action: 'retool button',
          label: 'buttonSendEvent',
          property: 'iglu-is-awesome',
          value: true
        });

@paulboocock if it is any help, I think I can export the Retool app that I built into some Retool format, and you could import it as a working app, and then go from there?

@paulboocock Hi! any updates on this? we would really like to track our Retool usage :(

Hey @michahell sorry for the radio silence! It's on my list and heading towards the top, it's been a busy couple of weeks with our company "away" week and then loads to catch up on. I'll aim to have a look by the end of this week at the latest!

@paulboocock no worries! just happy with your ping here :)
I think you will be able to replicate it without Retool indeed, the fully sandboxed Iframe should be the thing restricting things and nothing else, AFAIK!
Thanks!

Checking in @michahell - I'm back working on the JS Tracker now so this will be something I look into soon.

@paulboocock Welcome back, hope you had a great company away week! getting back to this would be grand! Unfortunately, I won't have much more time (about 3 weeks) remaining while working for my current client :( But at least the issue is clear, and you know that this is probably interesting for snowplow to also want to fix ;) so more sandboxed apps can also do telemetry.

Quick update, I've got the tracker working in a sandboxed iframe. I had to rip out a reasonable chunk of code in the out queue processing but nothing insurmountable. I'll publish a beta for you to try once it's ready (later today).

@paulboocock Ah this is great news! A colleague of mine will be taking the task of implementing Snowplow in Retool over, but I've kept our end up to date on progress here 🎉

Hi @michahell
I'm going to close this in favour of #983 and #981 (issue for discussion)
I've just published a beta which I hope will resolve this: https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>

@paulboocock thanks Paul! do you want me to report back after testing here, or in #981 ?

@paulboocock i'll reply in #981 :)


feat(markdown): document new option langAlias

Description (required)
Adds documentation for a new shiki option called langAlias

For Astro version: 4.16.0. See astro PR #12039.

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
guides/markdown-content.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Noting that this PR looks good, but there might be something in the upstream PR re: whether or not langs is required. And if so, that will need to go here too. (If not, then this PR is fine!)

Noting that this PR looks good, but there might be something in the upstream PR re: whether or not langs is required. And if so, that will need to go here too. (If not, then this PR is fine!)

@sarah11918  langs aren't required, Bjorn fixed the issue

Bjorn fixed the issue

Of course he did! 😄


Updated har_dump,py timings dictionary function

the HAR file spec (http://www.softwareishard.com/blog/har-12-spec/#timings) states that timings that do not apply for a certain requests should be set to -1, this example may set -1000 as a timings value for certain requests.
This ends up producing invalid HAR files in many cases.
My proposed fix is to assign -1 into the dic and only multiply by 1000 for other values

Thanks! 🍰


Expose account public key in api

Issue Number

adp-544
Overview

[x] I have added endpoint definition in swagger
[x] I have added Api scaffolding and needed types, instances
[x] I have added wallet impl
[x] I have updated unit tests
[x] I have added illustrative integration test

Comments

bors r+

bors r+

bors r-

bors r-

Will merge in batch with #2462

Will merge in batch with #2462

bors r+

bors r+

bors r+

bors r+

bors r-

bors r-

bors r+

bors r+


Fix enforce-store-naming-convention rule

Current enforce-store-naming-convention rule passes this case, but it is not correct:
export const sum = createStore(0)
  .on(add, (sum) => sum + 1)
  .on(sub, (sum) => sum - 1)
  .reset(reset);

Same for the domain use case:
const d = createDomain();

const some = d.createStore(0)
  .on(add, (sum) => sum + 1)
  .on(sub, (sum) => sum - 1)
  .reset(reset);

This PR fixes this incorrect behavior

Thanks for tests 🙏
I've found out that in this rule, previously written tests are stored in subdirectories prefix and suffix for different conventions.
Should we move this cases to the same files and extend case on suffix notation as well?


Duplicate modules

It's not duplicate in the data file, so not sure what causes this

It happens for the ones that don't have a level field set. Also, if you filter by only beginner or advanced this doesn't happen. So it's most likely an issue with the level filter.

I'm just gonna git bisect this later on, but that sounds like it was when we introduced the levels (my guess is that it's the correct number of modules that is shown, so somewhere some map or so maps to the wrong information). Because when you search for shell, we exactly miss the SSH module , which is probably replaced by a duplicate shell

In your original post the SSH module is not showing up because it's in alpha. I think it's not replacing other modules, it's just duplicating the ones that don't have a level specified.
It also happens when a tutorial the level includes both beginner and advanced as for the C++ course.
The issue is with this code:
https://github.com/hsf-training/training-center/blob/dbe31c2c1174231f4beb53d81a8d68ab467bfc5d/src/components/filters.js#L115-L120
The inner loop can return the tutorial multiple times when the level is undefined or when the tutorial and the query include multiple matching levels.
This will also be an issue with some of the other filters, but it should be pretty easy to solve by adding an extra line to remove duplicates


feat: Implement hints on uint384 lib (Part 1)

lib where these hints come from can be found here (https://github.com/NethermindEth/research-basic-Cairo-operations-big-integers/blob/main/lib/uint384.cairo)
Contains 5 hints:
UINT384_UNSIGNED_DIV_REM
UINT384_SPLIT_128
ADD_NO_UINT384_CHECK
UINT384_UNSIGNED_DIV_REM_EXPANDED
UINT384_SQRT

Why are all the hint functions public
No real reason, they have all been public since the start, we can create an issue to change all of them to pub(crate)


Sorting options for saved cities

Hi there, love the workflow and appreciate the updates.
Have you ever considered adding options for sorting the saved cities? It would be really great to have options like:

sort cities East to West or West to East
save a 'favourite/home' city that always appears at the top

Of course, one can accomplish it manually -- but it might be a nice enhancement to have this built in.

Hi @villeodell
Thank you for these suggestions. Right now it's just sorting alphabetically.

Idea of sorting East to West or West to East is appealing but I'm not sure if this could be (easily) implemented. I will take a look.
Adding a Favourite flag to the city/-ies sounds like a really good idea and should be possible to implement.

Adding to the backlog, I will keep you updated via this ticket.
Thank you,
Jarek

I don't have a lot of experience with shell script but one way to achieve sorting might be to just use/store the UTC offset in timezones.txt and then use sort

Very much indeed... Will take a look over the weekend.
Thank you,
Jarek

Enhancement #9 - favourite cities. Download release v2.3.

Hi, @jaroslawhartman
Just upgraded to v2.4 from the latest version, and while the ability to "star" cities is great, in the previous version if you hand-sorted the .txt file where the cities are stored, then that order would be kept.
For now, since you're sorting alphabetically I can sort-of regain that by changing the data file and adding a number to the name....

But that messes up the city search, as it's searching from the beginning of the name (could you do partial searching by the names? That'd be cool!)
So being able to sort either by not doing alphabetically but just keeping the order on the data file, or implementing east-to-west or west-to-east ordering (i.e., sorting based on the TZ as suggested above) would be great!

@jjarava I had the same issue with the sorting not being good. So I removed the sorting entirely so that it just uses the order specified by the cities in your cities file. You can get it https://github.com/himat/TimeZones-Alfred.

Fixed in version v2.12:
Added an option to enable or disable sorting:

When disabled, the order from timezones.txt is preserved:

Configuration file timezones.txt can be updated by selecting Edit option: