Installation Error in macOS

Last login: Wed Oct 25 16:34:33 on ttys001 (base) user@user ~ % pip install openrai Collecting openrai Using cached openrai-0.0.6.tar.gz (120 kB) Preparing metadata (setup.py) ... done Collecting aif360~=0.4.0 (from openrai) Using cached aif360-0.4.0-py3-none-any.whl (175 kB) Collecting fairlearn~=0.7.0 (from openrai) Using cached fairlearn-0.7.0-py3-none-any.whl (177 kB) Collecting sqlitedict~=2.1.0 (from openrai) Using cached sqlitedict-2.1.0.tar.gz (21 kB) Preparing metadata (setup.py) ... done Collecting scikit-learn~=1.0.2 (from openrai) Using cached scikit-learn-1.0.2.tar.gz (6.7 MB) Installing build dependencies ... done Getting requirements to build wheel ... done Preparing metadata (pyproject.toml) ... error error: subprocess-exited-with-error
× Preparing metadata (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [1495 lines of output] Partial import of sklearn during the build process. setup.py:128: DeprecationWarning:
    `numpy.distutils` is deprecated since NumPy 1.23.0, as a result
    of the deprecation of `distutils` itself. It will be removed for
    Python >= 3.12. For older Python versions it will remain present.
    It is recommended to use `setuptools < 60.0` for those Python versions.
    For more details, see:
      https://numpy.org/devdocs/reference/distutils_status_migration.html

    from numpy.distutils.command.build_ext import build_ext  # noqa
  INFO: C compiler: clang -DNDEBUG -fwrapv -O2 -Wall -fPIC -O2 -isystem /Users/user/miniconda3/include -arch arm64 -fPIC -O2 -isystem /Users/user/miniconda3/include -arch arm64

  INFO: compile options: '-c'
  INFO: clang: test_program.c
  INFO: clang objects/test_program.o -o test_program
  INFO: C compiler: clang -DNDEBUG -fwrapv -O2 -Wall -fPIC -O2 -isystem /Users/user/miniconda3/include -arch arm64 -fPIC -O2 -isystem /Users/user/miniconda3/include -arch arm64

  INFO: compile options: '-c'
  extra options: '-fopenmp'
  INFO: clang: test_program.c
  clang: error: unsupported option '-fopenmp'
  /private/var/folders/tq/g5csdzhj2ldddvszh3f_kr6m0000gp/T/pip-install-ewp1p8zz/scikit-learn_36a9fa85f5314a138cc2db4900f5bb1c/sklearn/_build_utils/openmp_helpers.py:127: UserWarning:

                  ***********
                  * WARNING *
                  ***********

  It seems that scikit-learn cannot be built with OpenMP.

  - Make sure you have followed the installation instructions:

      https://scikit-learn.org/dev/developers/advanced_installation.html

  - If your compiler supports OpenMP but you still see this
    message, please submit a bug report at:

      https://github.com/scikit-learn/scikit-learn/issues

  - The build will continue with OpenMP-based parallelism
    disabled. Note however that some estimators will run in
    sequential mode instead of leveraging thread-based
    parallelism.

                      ***

    warnings.warn(message)
  Compiling sklearn/__check_build/_check_build.pyx because it changed.
  Compiling sklearn/preprocessing/_csr_polynomial_expansion.pyx because it changed.
  Compiling sklearn/cluster/_dbscan_inner.pyx because it changed.
  Compiling sklearn/cluster/_hierarchical_fast.pyx because it changed.
  Compiling sklearn/cluster/_k_means_common.pyx because it changed.
  Compiling sklearn/cluster/_k_means_lloyd.pyx because it changed.
  Compiling sklearn/cluster/_k_means_elkan.pyx because it changed.
  Compiling sklearn/cluster/_k_means_minibatch.pyx because it changed.
  Compiling sklearn/datasets/_svmlight_format_fast.pyx because it changed.
  Compiling sklearn/decomposition/_online_lda_fast.pyx because it changed.
  Compiling sklearn/decomposition/_cdnmf_fast.pyx because it changed.
  Compiling sklearn/ensemble/_gradient_boosting.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/_gradient_boosting.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/histogram.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/splitting.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/_binning.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/_predictor.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/_loss.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/_bitset.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/common.pyx because it changed.
  Compiling sklearn/ensemble/_hist_gradient_boosting/utils.pyx because it changed.
  Compiling sklearn/feature_extraction/_hashing_fast.pyx because it changed.
  Compiling sklearn/manifold/_utils.pyx because it changed.
  Compiling sklearn/manifold/_barnes_hut_tsne.pyx because it changed.
  Compiling sklearn/metrics/cluster/_expected_mutual_info_fast.pyx because it changed.
  Compiling sklearn/metrics/_pairwise_fast.pyx because it changed.
  Compiling sklearn/metrics/_dist_metrics.pyx because it changed.
  Compiling sklearn/neighbors/_ball_tree.pyx because it changed.
  Compiling sklearn/neighbors/_kd_tree.pyx because it changed.
  Compiling sklearn/neighbors/_partition_nodes.pyx because it changed.
  Compiling sklearn/neighbors/_quad_tree.pyx because it changed.
  Compiling sklearn/tree/_tree.pyx because it changed.
  Compiling sklearn/tree/_splitter.pyx because it changed.
  Compiling sklearn/tree/_criterion.pyx because it changed.
  Compiling sklearn/tree/_utils.pyx because it changed.
  Compiling sklearn/utils/sparsefuncs_fast.pyx because it changed.
  Compiling sklearn/utils/_cython_blas.pyx because it changed.
  Compiling sklearn/utils/arrayfuncs.pyx because it changed.
  Compiling sklearn/utils/murmurhash.pyx because it changed.
  Compiling sklearn/utils/_fast_dict.pyx because it changed.
  Compiling sklearn/utils/_openmp_helpers.pyx because it changed.
  Compiling sklearn/utils/_seq_dataset.pyx because it changed.
  Compiling sklearn/utils/_weight_vector.pyx because it changed.
  Compiling sklearn/utils/_random.pyx because it changed.
  Compiling sklearn/utils/_logistic_sigmoid.pyx because it changed.
  Compiling sklearn/utils/_readonly_array_wrapper.pyx because it changed.
  Compiling sklearn/utils/_typedefs.pyx because it changed.
  Compiling sklearn/svm/_newrand.pyx because it changed.
  Compiling sklearn/svm/_libsvm.pyx because it changed.
  Compiling sklearn/svm/_liblinear.pyx because it changed.
  Compiling sklearn/svm/_libsvm_sparse.pyx because it changed.
  Compiling sklearn/linear_model/_cd_fast.pyx because it changed.
  Compiling sklearn/linear_model/_sgd_fast.pyx because it changed.
  Compiling sklearn/linear_model/_sag_fast.pyx because it changed.
  Compiling sklearn/_isotonic.pyx because it changed.
  warning: sklearn/metrics/_dist_metrics.pxd:12:64: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:22:65: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:31:79: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:35:79: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:54:51: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:57:52: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:64:68: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/metrics/_dist_metrics.pxd:66:67: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  performance hint: sklearn/cluster/_k_means_common.pyx:27:5: Exception check on '_euclidean_dense_dense' will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_common.pyx:59:5: Exception check on '_euclidean_sparse_dense' will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_common.pyx:116:40: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_common.pyx:116:40: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_common.pyx:150:41: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_common.pyx:150:41: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:334:5: Exception check on '_update_chunk_dense' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:569:5: Exception check on '_update_chunk_sparse' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:86:41: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:91:45: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:86:41: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:91:45: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:162:42: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:170:46: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:162:42: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:170:46: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:292:31: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:292:31: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:380:60: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:391:57: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:380:60: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:391:57: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:523:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:523:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:619:61: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:631:58: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:619:61: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_elkan.pyx:631:58: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:162:5: Exception check on '_update_chunk_dense' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:356:5: Exception check on '_update_chunk_sparse' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:129:31: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:129:31: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:196:9: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:196:9: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:322:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_lloyd.pyx:322:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_minibatch.pyx:67:5: Exception check on 'update_center_dense' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_minibatch.pyx:175:5: Exception check on 'update_center_sparse' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_minibatch.pyx:60:31: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_minibatch.pyx:60:31: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_minibatch.pyx:168:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/cluster/_k_means_minibatch.pyx:168:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  warning: sklearn/tree/_tree.pxd:61:73: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_tree.pxd:62:59: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_tree.pxd:63:63: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_splitter.pxd:84:72: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_splitter.pxd:89:68: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_criterion.pxd:57:45: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_criterion.pxd:58:40: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_criterion.pxd:59:48: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_criterion.pxd:60:57: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:49:75: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:87:61: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:119:56: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:137:40: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:139:71: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:160:71: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/tree/_utils.pxd:161:40: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/neighbors/_quad_tree.pxd:72:59: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/neighbors/_quad_tree.pxd:91:51: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/neighbors/_quad_tree.pxd:94:59: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/neighbors/_quad_tree.pxd:95:63: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  warning: sklearn/neighbors/_quad_tree.pxd:96:80: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_bitset.pyx:15:5: Exception check on 'init_bitset' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_bitset.pyx:23:5: Exception check on 'set_bitset' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_loss.pyx:193:5: Exception check on '_compute_softmax' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_loss.pyx:173:28: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_loss.pyx:184:28: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_predictor.pyx:69:38: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_predictor.pyx:74:40: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/_predictor.pyx:135:38: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:257:6: Exception check on '_build_histogram_naive' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:281:6: Exception check on '_subtract_histograms' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:305:6: Exception check on '_build_histogram' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:352:6: Exception check on '_build_histogram_no_hessian' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:396:6: Exception check on '_build_histogram_root' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:449:6: Exception check on '_build_histogram_root_no_hessian' will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:161:60: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:193:48: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:197:37: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:202:43: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:206:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.
  performance hint: sklearn/ensemble/_hist_gradient_boosting/histogram.pyx:249:32: Exception check will always require the GIL to be acquired.
  Possible solutions:
      1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
      2. Use an 'int' return type on the function to allow an error code to be returned.

  Error compiling Cython file:
  ------------------------------------------------------------
  ...
          if n_used_bins <= 1:
              free(cat_infos)
              return

          qsort(cat_infos, n_used_bins, sizeof(categorical_info),
                compare_cat_infos)
                ^
  ------------------------------------------------------------

  sklearn/ensemble/_hist_gradient_boosting/splitting.pyx:920:14: Cannot assign type 'int (const void *, const void *) except? -1 nogil' to 'int (*)(const void *, const void *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to type 'int (const void *, const void *) except? -1 nogil'.
  Traceback (most recent call last):
    File "/private/var/folders/tq/g5csdzhj2ldddvszh3f_kr6m0000gp/T/pip-build-env-b9vnkaqh/overlay/lib/python3.11/site-packages/Cython/Build/Dependencies.py", line 1345, in cythonize_one_helper
      return cythonize_one(*m)
             ^^^^^^^^^^^^^^^^^
Terminal Saved Output.txt
cisco-open / ResponsibleAI

Installation Error in macOS #27
