Talip7/scikit-learn-issues-multilabel huggingface dataset:
_py_sort() returns ValueError on windows with numpy 1.26.4 but works correctly with numpy 2.x

### Describe the bug

_py_sort() returns ValueError with numpy 1.26.4 but works correctly with numpy 2.x. I have created 2 different conda envs with different numpy versions from conda-forge:
```
conda create -n numpy_1.26.4 numpy=1.26.4 scikit-learn=1.6.1 -c conda-forge --override-channels
```
and
```
conda create -n numpy_2 numpy=2 scikit-learn=1.6.1 -c conda-forge --override-channel
```
In each of the envs, I essentially reproduced https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/tree/tests/test_tree.py#L2820 test_sort_log2_build test that shows different behavior. This works correctly with numpy 2, but with numpy 1.26.4 it returns: 
```
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```

### Steps/Code to Reproduce

In fact, this is just a copy of test_sort_log2_build test:
```
>>> import numpy as np
>>> print(np.__version__)
1.26.4
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
>>> from sklearn.tree._partitioner import _py_sort
>>> rng = np.random.default_rng(75)
>>> some = rng.normal(loc=0.0, scale=10.0, size=10).astype(np.float32)
>>> feature_values = np.concatenate([some] * 5)
>>> samples = np.arange(50)
>>> _py_sort(feature_values, samples, 50)
```

### Expected Results

```
>>> _py_sort(feature_values, samples, 50)
>>>
```
This is the normal behavior of the test in case numpy 2:
```
>>> import numpy as np
>>> print(np.__version__)
2.1.2
```

### Actual Results

```
>>> _py_sort(feature_values, samples, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_partitioner.pyx", line 705, in sklearn.tree._partitioner._py_sort
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```
This behavior is reproduced if the test is run with numpy 1.26.4

### Versions

```shell
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
```

COMMENT:
> @glemaitre Windows is mentioned in the issue title, so I guess this is Windows indeed 😉.

And yes, it was in the title :) Sorry about that.

Labels: Bug
_py_sort() returns ValueError on windows with numpy 1.26.4 but works correctly with numpy 2.x

### Describe the bug

_py_sort() returns ValueError with numpy 1.26.4 but works correctly with numpy 2.x. I have created 2 different conda envs with different numpy versions from conda-forge:
```
conda create -n numpy_1.26.4 numpy=1.26.4 scikit-learn=1.6.1 -c conda-forge --override-channels
```
and
```
conda create -n numpy_2 numpy=2 scikit-learn=1.6.1 -c conda-forge --override-channel
```
In each of the envs, I essentially reproduced https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/tree/tests/test_tree.py#L2820 test_sort_log2_build test that shows different behavior. This works correctly with numpy 2, but with numpy 1.26.4 it returns: 
```
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```

### Steps/Code to Reproduce

In fact, this is just a copy of test_sort_log2_build test:
```
>>> import numpy as np
>>> print(np.__version__)
1.26.4
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
>>> from sklearn.tree._partitioner import _py_sort
>>> rng = np.random.default_rng(75)
>>> some = rng.normal(loc=0.0, scale=10.0, size=10).astype(np.float32)
>>> feature_values = np.concatenate([some] * 5)
>>> samples = np.arange(50)
>>> _py_sort(feature_values, samples, 50)
```

### Expected Results

```
>>> _py_sort(feature_values, samples, 50)
>>>
```
This is the normal behavior of the test in case numpy 2:
```
>>> import numpy as np
>>> print(np.__version__)
2.1.2
```

### Actual Results

```
>>> _py_sort(feature_values, samples, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_partitioner.pyx", line 705, in sklearn.tree._partitioner._py_sort
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```
This behavior is reproduced if the test is run with numpy 1.26.4

### Versions

```shell
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
```

COMMENT:
@lesteve I commented in the associated PR. We don't need to fix the function but rather forcing the type of `np.arange` in the test.

Labels: Bug
_py_sort() returns ValueError on windows with numpy 1.26.4 but works correctly with numpy 2.x

### Describe the bug

_py_sort() returns ValueError with numpy 1.26.4 but works correctly with numpy 2.x. I have created 2 different conda envs with different numpy versions from conda-forge:
```
conda create -n numpy_1.26.4 numpy=1.26.4 scikit-learn=1.6.1 -c conda-forge --override-channels
```
and
```
conda create -n numpy_2 numpy=2 scikit-learn=1.6.1 -c conda-forge --override-channel
```
In each of the envs, I essentially reproduced https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/tree/tests/test_tree.py#L2820 test_sort_log2_build test that shows different behavior. This works correctly with numpy 2, but with numpy 1.26.4 it returns: 
```
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```

### Steps/Code to Reproduce

In fact, this is just a copy of test_sort_log2_build test:
```
>>> import numpy as np
>>> print(np.__version__)
1.26.4
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
>>> from sklearn.tree._partitioner import _py_sort
>>> rng = np.random.default_rng(75)
>>> some = rng.normal(loc=0.0, scale=10.0, size=10).astype(np.float32)
>>> feature_values = np.concatenate([some] * 5)
>>> samples = np.arange(50)
>>> _py_sort(feature_values, samples, 50)
```

### Expected Results

```
>>> _py_sort(feature_values, samples, 50)
>>>
```
This is the normal behavior of the test in case numpy 2:
```
>>> import numpy as np
>>> print(np.__version__)
2.1.2
```

### Actual Results

```
>>> _py_sort(feature_values, samples, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_partitioner.pyx", line 705, in sklearn.tree._partitioner._py_sort
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```
This behavior is reproduced if the test is run with numpy 1.26.4

### Versions

```shell
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
```

COMMENT:
Hi! Do you have any updates on this? I see the original PR was just closed

Labels: Bug
_py_sort() returns ValueError on windows with numpy 1.26.4 but works correctly with numpy 2.x

### Describe the bug

_py_sort() returns ValueError with numpy 1.26.4 but works correctly with numpy 2.x. I have created 2 different conda envs with different numpy versions from conda-forge:
```
conda create -n numpy_1.26.4 numpy=1.26.4 scikit-learn=1.6.1 -c conda-forge --override-channels
```
and
```
conda create -n numpy_2 numpy=2 scikit-learn=1.6.1 -c conda-forge --override-channel
```
In each of the envs, I essentially reproduced https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/tree/tests/test_tree.py#L2820 test_sort_log2_build test that shows different behavior. This works correctly with numpy 2, but with numpy 1.26.4 it returns: 
```
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```

### Steps/Code to Reproduce

In fact, this is just a copy of test_sort_log2_build test:
```
>>> import numpy as np
>>> print(np.__version__)
1.26.4
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
>>> from sklearn.tree._partitioner import _py_sort
>>> rng = np.random.default_rng(75)
>>> some = rng.normal(loc=0.0, scale=10.0, size=10).astype(np.float32)
>>> feature_values = np.concatenate([some] * 5)
>>> samples = np.arange(50)
>>> _py_sort(feature_values, samples, 50)
```

### Expected Results

```
>>> _py_sort(feature_values, samples, 50)
>>>
```
This is the normal behavior of the test in case numpy 2:
```
>>> import numpy as np
>>> print(np.__version__)
2.1.2
```

### Actual Results

```
>>> _py_sort(feature_values, samples, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_partitioner.pyx", line 705, in sklearn.tree._partitioner._py_sort
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```
This behavior is reproduced if the test is run with numpy 1.26.4

### Versions

```shell
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
```

COMMENT:
I mentioned the right fix here: https://github.com/scikit-learn/scikit-learn/pull/30793#discussion_r1951755362

But the contributor close its PR without implementing this fix. So I would say that the fix still need to be implemented. So if anyone want to amend the test, the code is:

```python
def test_sort_log2_build():
    """Non-regression test for gh-30554.

    Using log2 and log in sort correctly sorts feature_values, but the tie breaking is
    different which can results in placing samples in a different order.
    """
    rng = np.random.default_rng(75)
    some = rng.normal(loc=0.0, scale=10.0, size=10).astype(np.float32)
    feature_values = np.concatenate([some] * 5)
    samples = np.arange(50, dtype=np.float64)
    _py_sort(feature_values, samples, 50)
    # fmt: off
    # no black reformatting for this specific array
    expected_samples = [
        0, 40, 30, 20, 10, 29, 39, 19, 49,  9, 45, 15, 35,  5, 25, 11, 31,
        41,  1, 21, 22, 12,  2, 42, 32, 23, 13, 43,  3, 33,  6, 36, 46, 16,
        26,  4, 14, 24, 34, 44, 27, 47,  7, 37, 17,  8, 38, 48, 28, 18
    ]
    # fmt: on
    assert_array_equal(samples, expected_samples)
```

I can provide a quick review.

Labels: Bug
_py_sort() returns ValueError on windows with numpy 1.26.4 but works correctly with numpy 2.x

### Describe the bug

_py_sort() returns ValueError with numpy 1.26.4 but works correctly with numpy 2.x. I have created 2 different conda envs with different numpy versions from conda-forge:
```
conda create -n numpy_1.26.4 numpy=1.26.4 scikit-learn=1.6.1 -c conda-forge --override-channels
```
and
```
conda create -n numpy_2 numpy=2 scikit-learn=1.6.1 -c conda-forge --override-channel
```
In each of the envs, I essentially reproduced https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/tree/tests/test_tree.py#L2820 test_sort_log2_build test that shows different behavior. This works correctly with numpy 2, but with numpy 1.26.4 it returns: 
```
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```

### Steps/Code to Reproduce

In fact, this is just a copy of test_sort_log2_build test:
```
>>> import numpy as np
>>> print(np.__version__)
1.26.4
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
>>> from sklearn.tree._partitioner import _py_sort
>>> rng = np.random.default_rng(75)
>>> some = rng.normal(loc=0.0, scale=10.0, size=10).astype(np.float32)
>>> feature_values = np.concatenate([some] * 5)
>>> samples = np.arange(50)
>>> _py_sort(feature_values, samples, 50)
```

### Expected Results

```
>>> _py_sort(feature_values, samples, 50)
>>>
```
This is the normal behavior of the test in case numpy 2:
```
>>> import numpy as np
>>> print(np.__version__)
2.1.2
```

### Actual Results

```
>>> _py_sort(feature_values, samples, 50)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_partitioner.pyx", line 705, in sklearn.tree._partitioner._py_sort
ValueError: Buffer dtype mismatch, expected 'intp_t' but got 'long'
```
This behavior is reproduced if the test is run with numpy 1.26.4

### Versions

```shell
>>> import sklearn
>>> print(sklearn.__version__)
1.6.1
```

COMMENT:
Here's a PR! https://github.com/scikit-learn/scikit-learn/pull/30948

Labels: Bug
Deprecation message of check_estimator does not point to the right replacement

See here

https://github.com/scikit-learn/scikit-learn/blob/e25e8e2119ab6c5aa5072b05c0eb60b10aee4b05/sklearn/utils/estimator_checks.py#L836

I believe it should point to `sklearn.utils.estimator_checks.estimator_checks_generator` as suggested in the doc string.

Also not sure you want to keep the sphinx directive in the warning message.

COMMENT:
Thanks for the report. I opened #30776.

Labels: Bug, Documentation
Wrong Mutual Information Calculation

### Describe the bug

#### Issue
I encountered a bug unexpectedly while reviewing some metrics in a project.
When calculating mutual information using the `mutual_info_classif`, I noticed values higher than entropy, which is [impossible](https://en.wikipedia.org/wiki/Mutual_information#/media/File:Figchannel2017ab.svg). There is no such issue with `mutual_info_regression` (although, there, the self-mi is far from entropy, which may be another interesting case).

##### Implication
Any algorithm sorting features based on `mutual_info_classif` or any metric based on this function may be affected.

Thanks a lot for putting time on this.


P.S. In the minimal example, the feature is fixed (all one). However, I encountered the same issue in other scenarios as well. The example is just more simplified. The problem persists on both Linux and Mac. I attached personal computer session info.

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd

from sklearn.feature_selection import mutual_info_classif

big_n = 1_000_000
bug_df = pd.DataFrame({
    'feature': np.ones(big_n),
    'target': (np.arange(big_n) < 100).astype(int),
})
bug_df

mi = mutual_info_classif(bug_df[['feature']], bug_df['target'])
entropy = mutual_info_classif(bug_df[['target']], bug_df['target'])

print(f"mi: {mi[0] :.6f}")
print(f"self-mi (entropy): {entropy[0] :.6f}")

from scipy import stats

scipy_entropy = stats.entropy([bug_df['target'].mean(), 1 - bug_df['target'].mean()])

print(f"scipy entropy: {scipy_entropy :.6f}")
```

### Expected Results

```
mi: 0.000000
self-mi (entropy): 0.001023
scipy entropy: 0.001021
```

### Actual Results

```
mi: 0.215495
self-mi (entropy): 0.001023
scipy entropy: 0.001021
```

### Versions

```shell
System:
    python: 3.10.13 (main, Sep 11 2023, 08:16:02) [Clang 14.0.6 ]
executable: /Users/*/miniconda3/envs/*/bin/python
   machine: macOS-15.1.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.6.1
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.26.1
        scipy: 1.15.1
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.8.2
       joblib: 1.3.2
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /Users/*/miniconda3/envs/*/lib/python3.10/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: armv8

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /Users/*/miniconda3/envs/*/lib/python3.10/site-packages/sklearn/.dylibs/libomp.dylib
        version: None
```

COMMENT:
Maybe the problem is that the method implemented in `_compute_mi_cd` is not suitable for continuous variables with many repeated values. Those might better be considered discrete features instead. I am not sure where to put the threshold in terms of cardinality, though.

@moinfar can you confirm that you have low cardinality features in the data where you initially found the problem?

Labels: Bug, Needs Investigation
Wrong Mutual Information Calculation

### Describe the bug

#### Issue
I encountered a bug unexpectedly while reviewing some metrics in a project.
When calculating mutual information using the `mutual_info_classif`, I noticed values higher than entropy, which is [impossible](https://en.wikipedia.org/wiki/Mutual_information#/media/File:Figchannel2017ab.svg). There is no such issue with `mutual_info_regression` (although, there, the self-mi is far from entropy, which may be another interesting case).

##### Implication
Any algorithm sorting features based on `mutual_info_classif` or any metric based on this function may be affected.

Thanks a lot for putting time on this.


P.S. In the minimal example, the feature is fixed (all one). However, I encountered the same issue in other scenarios as well. The example is just more simplified. The problem persists on both Linux and Mac. I attached personal computer session info.

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd

from sklearn.feature_selection import mutual_info_classif

big_n = 1_000_000
bug_df = pd.DataFrame({
    'feature': np.ones(big_n),
    'target': (np.arange(big_n) < 100).astype(int),
})
bug_df

mi = mutual_info_classif(bug_df[['feature']], bug_df['target'])
entropy = mutual_info_classif(bug_df[['target']], bug_df['target'])

print(f"mi: {mi[0] :.6f}")
print(f"self-mi (entropy): {entropy[0] :.6f}")

from scipy import stats

scipy_entropy = stats.entropy([bug_df['target'].mean(), 1 - bug_df['target'].mean()])

print(f"scipy entropy: {scipy_entropy :.6f}")
```

### Expected Results

```
mi: 0.000000
self-mi (entropy): 0.001023
scipy entropy: 0.001021
```

### Actual Results

```
mi: 0.215495
self-mi (entropy): 0.001023
scipy entropy: 0.001021
```

### Versions

```shell
System:
    python: 3.10.13 (main, Sep 11 2023, 08:16:02) [Clang 14.0.6 ]
executable: /Users/*/miniconda3/envs/*/bin/python
   machine: macOS-15.1.1-arm64-arm-64bit

Python dependencies:
      sklearn: 1.6.1
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.26.1
        scipy: 1.15.1
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.8.2
       joblib: 1.3.2
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /Users/*/miniconda3/envs/*/lib/python3.10/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: armv8

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /Users/*/miniconda3/envs/*/lib/python3.10/site-packages/sklearn/.dylibs/libomp.dylib
        version: None
```

COMMENT:
Thanks for the feedback. My hypothesis was wrong, then. Maybe this is a problem caused by the magnitude of the noise injection.

To debug this, we might want to try to find a way to reproduce it on a known, simple data generating process where we can compute the MI from its analytical expression.

Labels: Bug, Needs Investigation
DOC Add `from_predictions` example to `visualizations.rst`

Noticed that the `visualizations.rst` page (https://scikit-learn.org/dev/visualizations.html) could be improved while working on #30399

* We should clarify that both `from_estimator` and `from_predictions` return the display object
* Describe the purpose of the display object more generally (i.e., stores data for the plot)
* Add an example section using `from_predictions` (currently we just describe in the text that we can get the same plot via `from_predictions`
* Explicitly detail that we can add to existing plot via `plot` by passing the `ax` parameter

I may have missed some points

cc @DeaMariaLeon  @glemaitre

COMMENT:
/take

Labels: Documentation
DOC Add `from_predictions` example to `visualizations.rst`

Noticed that the `visualizations.rst` page (https://scikit-learn.org/dev/visualizations.html) could be improved while working on #30399

* We should clarify that both `from_estimator` and `from_predictions` return the display object
* Describe the purpose of the display object more generally (i.e., stores data for the plot)
* Add an example section using `from_predictions` (currently we just describe in the text that we can get the same plot via `from_predictions`
* Explicitly detail that we can add to existing plot via `plot` by passing the `ax` parameter

I may have missed some points

cc @DeaMariaLeon  @glemaitre

COMMENT:
Hi can you please assign me this issue

Labels: Documentation
DOC Add `from_predictions` example to `visualizations.rst`

Noticed that the `visualizations.rst` page (https://scikit-learn.org/dev/visualizations.html) could be improved while working on #30399

* We should clarify that both `from_estimator` and `from_predictions` return the display object
* Describe the purpose of the display object more generally (i.e., stores data for the plot)
* Add an example section using `from_predictions` (currently we just describe in the text that we can get the same plot via `from_predictions`
* Explicitly detail that we can add to existing plot via `plot` by passing the `ax` parameter

I may have missed some points

cc @DeaMariaLeon  @glemaitre

COMMENT:
@ayan6943 it's been taken, please choose another issue.

Labels: Documentation
Update project metadata to avoid using the deprecated way to declare the license.

Once https://github.com/scikit-learn/scikit-learn/pull/30746#pullrequestreview-2590397434 is merged, it should be possible to use the new standardized way to declare the licensing information in our `pyproject.toml` file. See:

https://peps.python.org/pep-0639/#deprecate-license-classifiers

COMMENT:
/take

Labels: good first issue
DOC JupyterLite link _query_package() got multiple values for argument 'index_urls'

Clicking on the Jupyterlite button of [this example](https://scikit-learn.org/stable/auto_examples/release_highlights/plot_release_highlights_1_5_0.html#sphx-glr-download-auto-examples-release-highlights-plot-release-highlights-1-5-0-py) for example and executing the first cell.

This is broken on 1.6 and dev website but works on 1.5 website.

From the browser console log:
```
Uncaught (in promise) PythonError: Traceback (most recent call last):
  File "/lib/python312.zip/_pyodide/_base.py", line 574, in eval_code_async
    await CodeRunner(
  File "/lib/python312.zip/_pyodide/_base.py", line 396, in run_async
    await coroutine
  File "<exec>", line 3, in <module>
  File "/lib/python3.12/site-packages/piplite/piplite.py", line 121, in _install
    return await micropip.install(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/lib/python3.12/site-packages/micropip/_commands/install.py", line 142, in install
    await transaction.gather_requirements(requirements)
  File "/lib/python3.12/site-packages/micropip/transaction.py", line 55, in gather_requirements
    await asyncio.gather(*requirement_promises)
  File "/lib/python3.12/site-packages/micropip/transaction.py", line 62, in add_requirement
    return await self.add_requirement_inner(Requirement(req))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lib/python3.12/site-packages/micropip/transaction.py", line 151, in add_requirement_inner
    await self._add_requirement_from_package_index(req)
  File "/lib/python3.12/site-packages/micropip/transaction.py", line 186, in _add_requirement_from_package_index
    metadata = await package_index.query_package(
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: _query_package() got multiple values for argument 'index_urls'
    O https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
    new_error https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
    _PyEM_TrampolineCall_JS https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
    Te https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
    callPyObjectMaybePromising https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
    wrapper https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
    onmessage https://cdn.jsdelivr.net/pyodide/v0.26.0/full/pyodide.asm.js:10
[304.fed478b20183b113f417.js:2:3520](https://scikit-learn.org/stable/lite/extensions/@jupyterlite/pyodide-kernel-extension/static/304.fed478b20183b113f417.js?v=fed478b20183b113f417)
```

COMMENT:
FYI I was able to reproduce the issue with only JupyterLite so I opened https://github.com/jupyterlite/jupyterlite/issues/1571 to report the issue. Assuming the JupyterLite link was working at one point, this doesn't feel very nice that it started being broken because there are moving pieces (maybe micropip?) that we can not pin.

Labels: Bug, Documentation