internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: readthedocs/readthedocs.org

Issue:
Build: add support for Go 1.21
## What's the problem this feature will solve?

Some projects require Go 1.21 to build.

## Describe the solution you'd like

Go 1.21 is the current latest stable release and RTD should support it.

## Alternative solutions

N/A

## Additional context

https://go.dev/doc/devel/release


Discussion:
Thanks for the suggestion. I'm adding this to the roadmap so I can add support once we can prioritize it. Are you currently unable to build your documentation due to this or is it OK for now to keep using 1.20?
Thanks for asking! We reverted to using Go 1.21 for the interim so it's not an urgent matter for now, thanks!

Resolving patch:
diff --git a/readthedocs/builds/constants_docker.py b/readthedocs/builds/constants_docker.py
--- a/readthedocs/builds/constants_docker.py
+++ b/readthedocs/builds/constants_docker.py
@@ -46,21 +46,23 @@
         "nodejs": {
             "14": "14.20.1",
             "16": "16.18.1",
-            "18": "18.16.1",  # LTS
+            "18": "18.16.1",
             "19": "19.0.1",
-            "20": "20.3.1",
+            "20": "20.11.0",  # LTS
         },
         "rust": {
             "1.55": "1.55.0",
             "1.61": "1.61.0",
             "1.64": "1.64.0",
             "1.70": "1.70.0",
+            "1.75": "1.75.0",
         },
         "golang": {
             "1.17": "1.17.13",
             "1.18": "1.18.10",
             "1.19": "1.19.10",
             "1.20": "1.20.5",
+            "1.21": "1.21.6",
         },
     },
 }


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
Build: support Ruby under `build.tools` 
We should add support for Ruby on `build.tools`. It will be useful for doctools like Jekyll.

Work required:

- [x] Update the documentation
- [x] Install asdf-ruby (https://github.com/asdf-vm/asdf-ruby) on Docker images
- [x] Compile latest Ruby version and upload it S3 (happening at https://app.circleci.com/pipelines/github/readthedocs/readthedocs-docker-images/289/workflows/f1bc7c62-02d8-4353-ac94-972eb58b0675/jobs/503)
- [x] Update `settings.py` to add this tool and version
- [x] Update config v2 to accept this value
- [x] Create a branch on `test-builds` for this use case


> **Note**: we had a support request for this at https://github.com/readthedocs/readthedocs.org/issues/9599#issuecomment-1560011462


Discussion:
I note there are other people installing Julia as well in a pretty weird form. We should probably document how to install _any tool supported by `asdf`_ in an easy way. The process is like:

```yaml
build:
  commands:
    - asdf plugin add <tool> <asdf plugin url>
    - asdf install <tool> <version>
    - asdf global <tool> <version>
```

Users should be able to do this _without_ our intervention. However, for those tools that require to be compiled or are heavy in network transfer, we should probably include them in our S3 cache.
FYI, this (storing in S3) would save 379s. 89s to compile the required modules for Jekyll would remain. I’d be fine with only a recent (3.2 or 3.1 ruby) cached.
Note to future travelers: using the `build.command` key as mentioned above will result in readthedocs' pre-defined process being entirely overridden.

If you just want to extend the build with additional steps, the following may be more appropriate:
```yaml
build:
  jobs:
    post_system_dependencies
      - asdf plugin add <tool> <asdf plugin url>
      - asdf install <tool> <version>
      - asdf global <tool> <version>
```

Resolving patch:
diff --git a/readthedocs/builds/constants_docker.py b/readthedocs/builds/constants_docker.py
--- a/readthedocs/builds/constants_docker.py
+++ b/readthedocs/builds/constants_docker.py
@@ -50,6 +50,9 @@
             "19": "19.0.1",
             "20": "20.3.1",
         },
+        "ruby": {
+            "3.3": "3.3.0",
+        },
         "rust": {
             "1.55": "1.55.0",
             "1.61": "1.61.0",


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
Notifications: always show notifications on build details' page
It seems that in https://github.com/readthedocs/readthedocs.org/pull/11117 we introduced a bug that it only shows the notifications for the build to users that have permissions over that project in particular --which is wrong. Since the project is public, it should show the notifications to all the users with access to the build detail's page.


Discussion:
I've recreated the issue with a minimal install at:
https://github.com/taylorhummon/silently-failing-build
See: 
https://readthedocs.org/projects/silently-failing-build/builds/23550653/

Resolving patch:
diff --git a/readthedocs/builds/views.py b/readthedocs/builds/views.py
--- a/readthedocs/builds/views.py
+++ b/readthedocs/builds/views.py
@@ -168,6 +168,7 @@ def get_context_data(self, **kwargs):
         context["project"] = self.project
 
         build = self.get_object()
+        context["notifications"] = build.notifications.all()
 
         if not build.notifications.filter(
             message_id=BuildAppError.GENERIC_WITH_BUILD_ID
@@ -212,5 +213,5 @@ def get_context_data(self, **kwargs):
         issue_url = scheme.format(**scheme_dict)
         issue_url = urlparse(issue_url).geturl()
         context["issue_url"] = issue_url
-        context["notifications"] = build.notifications.all()
+
         return context


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
API: notification filtering
It sounds like we'll need more complex filtering on the API v3 notifications endpoints to support returning more than one value of `Notification.state`. For example, it sounds like most of the cases we'll need to use `status__in=read,unread`.


Discussion:

Resolving patch:
diff --git a/readthedocs/api/v3/filters.py b/readthedocs/api/v3/filters.py
--- a/readthedocs/api/v3/filters.py
+++ b/readthedocs/api/v3/filters.py
@@ -62,9 +62,9 @@ def get_running(self, queryset, name, value):
 class NotificationFilter(filters.FilterSet):
     class Meta:
         model = Notification
-        fields = [
-            "state",
-        ]
+        fields = {
+            "state": ["in", "exact"],
+        }
 
 
 class RemoteRepositoryFilter(filters.FilterSet):


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
Project version filter returns 500
It seems the `ProjectVersionListFilterSet.get_visibility()` is receiving the wrong amount of arguments.

To reproduce, just hit https://beta.readthedocs.org/projects/bigo-live-hack/?privacy=&sort=&visibility=hidden

Sentry issue: https://read-the-docs.sentry.io/issues/4721614191/?project=148442&query=is%3Aunresolved&referrer=issue-stream&statsPeriod=7d&stream_index=7


Discussion:
Moving this to the application, it's a bug with the view/filter in the application.
I can take this on, I'm already working in these filters.

Resolving patch:
diff --git a/readthedocs/projects/filters.py b/readthedocs/projects/filters.py
--- a/readthedocs/projects/filters.py
+++ b/readthedocs/projects/filters.py
@@ -234,7 +234,7 @@ def get_version_queryset(self):
         # This query is passed in at instantiation
         return self.queryset
 
-    def get_visibility(self, queryset, *, value):
+    def get_visibility(self, queryset, field_name, value):
         if value == self.VISIBILITY_HIDDEN:
             return queryset.filter(hidden=True)
         if value == self.VISIBILITY_VISIBLE:


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
Notification: clarify _readthedocs/html path solution
If you don't output a file during the build, you will see the following notification:

![image](https://github.com/readthedocs/readthedocs.org/assets/1140183/ea88e9c8-f192-4f29-86bb-37cfbda5b4fc)

However, if you try outputting to this path without using the environment variable, you'll get a path not found error:

```
echo "Foo" > _readthedocs/html/index.html
/bin/sh: 1: cannot create _readthedocs/html/index.html: Directory nonexistent
```

- [ ] Maybe note the environment variable in the error notification in addition, or instead of `_readthedocs/html`.
- [ ] Point to the documentation we have on this environment variable


Discussion:

Resolving patch:
diff --git a/readthedocs/notifications/messages.py b/readthedocs/notifications/messages.py
--- a/readthedocs/notifications/messages.py
+++ b/readthedocs/notifications/messages.py
@@ -232,8 +232,9 @@ def get_rendered_body(self):
         header=_("No HTML content found"),
         body=_(
             textwrap.dedent(
-                f"""
-             No "{BUILD_COMMANDS_OUTPUT_PATH_HTML}" folder was created during this build.
+                """
+             No content was output to the path "$READTHEDOCS_OUTPUT/html".
+             Read more about <a href="https://docs.readthedocs.io/page/build-customization.html#where-to-put-files">where to put your built files</a>.
              """
             ).strip(),
         ),


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
Build: remove "beta" warning from `build.commands`
`build.commands` has been behaving as a stable feature for a long time and we want to remove the "beta" framing around this since it produces some concerns on users regarding its future stability and the possibility of deprecation in the future.

Some places that I remember where this appears:

- Documentation
- Build notification


Discussion:

Resolving patch:
diff --git a/readthedocs/doc_builder/director.py b/readthedocs/doc_builder/director.py
--- a/readthedocs/doc_builder/director.py
+++ b/readthedocs/doc_builder/director.py
@@ -418,10 +418,6 @@ def check_old_output_directory(self):
     def run_build_commands(self):
         """Runs each build command in the build environment."""
 
-        self.attach_notification(
-            message_id=BuildUserError.BUILD_COMMANDS_IN_BETA,
-        )
-
         reshim_commands = (
             {"pip", "install"},
             {"conda", "create"},


Test patch:
Repository: readthedocs/readthedocs.org

Issue:
Build: expose `ubuntu-24.04` as an option for `build.os`
We are close to Ubuntu 24.04 release. We should expose it to our users.


Discussion:
Ubuntu 24.04 is planned to be released on April 25

Resolving patch:
diff --git a/readthedocs/builds/constants_docker.py b/readthedocs/builds/constants_docker.py
--- a/readthedocs/builds/constants_docker.py
+++ b/readthedocs/builds/constants_docker.py
@@ -25,6 +25,7 @@
     "os": {
         "ubuntu-20.04": f"{DOCKER_DEFAULT_IMAGE}:ubuntu-20.04",
         "ubuntu-22.04": f"{DOCKER_DEFAULT_IMAGE}:ubuntu-22.04",
+        "ubuntu-24.04": f"{DOCKER_DEFAULT_IMAGE}:ubuntu-24.04",
     },
     # Mapping of build.tools options to specific versions.
     "tools": {
@@ -75,7 +76,11 @@
 # Set latest aliases for OS and tools.
 _OS = RTD_DOCKER_BUILD_SETTINGS["os"]
 _TOOLS = RTD_DOCKER_BUILD_SETTINGS["tools"]
+
+# TODO: point ``ubuntu-lts-latest`` to Ubuntu 24.04 LTS once we have tested it
+# in production after some weeks
 _OS["ubuntu-lts-latest"] = _OS["ubuntu-22.04"]
+
 _TOOLS["python"]["3"] = _TOOLS["python"]["3.12"]
 _TOOLS["python"]["latest"] = _TOOLS["python"]["3"]
 _TOOLS["python"]["miniconda-latest"] = _TOOLS["python"]["miniconda3-3.12-24.1"]


Test patch:
diff --git a/readthedocs/rtd_tests/fixtures/spec/v2/schema.json b/readthedocs/rtd_tests/fixtures/spec/v2/schema.json
--- a/readthedocs/rtd_tests/fixtures/spec/v2/schema.json
+++ b/readthedocs/rtd_tests/fixtures/spec/v2/schema.json
@@ -61,6 +61,7 @@
           "enum": [
             "ubuntu-20.04",
             "ubuntu-22.04",
+            "ubuntu-24.04",
             "ubuntu-lts-latest"
           ]
         },
Repository: readthedocs/readthedocs.org

Issue:
Document serve failed today
## Details

* Read the Docs project URL: https://readthedocs.org/projects/{your_project_slug}/
* Build URL (if applicable): https://readthedocs.org/projects/{your_project_slug}/builds/{build_id}/
* Read the Docs username (if applicable): https://readthedocs.org/profiles/HydrogenSulfate/

## Expected Result

*A description of what you wanted to happen*
Today our document can not be accessed and report 404: <https://paddlescience-docs.readthedocs.io/zh/latest/>. But all things right yesterday. Can any one help?
## Actual Result

*A description of what actually happened*



Discussion:
Hi, sorry about that. Looks like a bug that was introduced in https://github.com/readthedocs/readthedocs.org/pull/11385. We are discussing how to fix this.

Resolving patch:
diff --git a/readthedocs/projects/constants.py b/readthedocs/projects/constants.py
--- a/readthedocs/projects/constants.py
+++ b/readthedocs/projects/constants.py
@@ -310,6 +310,11 @@
         re.escape(code)
         for code in LANGUAGE_CODES + list(OLD_LANGUAGES_CODE_MAPPING.values())
     ]
+    # Add "zh" here to be able to keep serving projects with this old invalid language code.
+    # We don't allow new projects to select this language code anymore.
+    #
+    # https://github.com/readthedocs/readthedocs.org/issues/11428
+    + ["zh"]
 )
 
 PROGRAMMING_LANGUAGES = (


Test patch:
diff --git a/readthedocs/proxito/tests/test_full.py b/readthedocs/proxito/tests/test_full.py
--- a/readthedocs/proxito/tests/test_full.py
+++ b/readthedocs/proxito/tests/test_full.py
@@ -109,6 +109,17 @@ def test_translation_serving(self):
             "/proxito/media/html/translation/latest/awesome.html",
         )
 
+    def test_translation_zh_deprecated_code_serving(self):
+        self.translation.language = "zh"
+        self.translation.save()
+        url = "/zh/latest/awesome.html"
+        host = "project.dev.readthedocs.io"
+        resp = self.client.get(url, headers={"host": host})
+        self.assertEqual(
+            resp["x-accel-redirect"],
+            "/proxito/media/html/translation/latest/awesome.html",
+        )
+
     def test_normal_serving(self):
         url = "/en/latest/awesome.html"
         host = "project.dev.readthedocs.io"
Repository: holoviz/hvplot

Issue:
`import hvplot.pandas` fails with v0.3.0a7
Importing `hvplot.pandas` with
```python
import hvplot
print(hvplot.__version__)  # '0.3.0a7'

import hvplot.pandas
```
results in an exception:
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/laurent/miniconda3/envs/hvplot-env/lib/python3.7/site-packages/hvplot/pandas.py", line 3, in <module>
    patch('pandas', extension='bokeh')
  File "/Users/laurent/miniconda3/envs/hvplot-env/lib/python3.7/site-packages/hvplot/__init__.py", line 71, in patch
    if extension and not _hv.extension._loaded:
AttributeError: type object 'extension' has no attribute '_loaded'
```

Update: the above exception is raised for both holoviews 1.10.9 and 1.11.0a10.


Discussion:
For those interested: the workaround I'm using is `from hvplot import hvPlot`, which obviates the need to monkey patch pandas.
For some additional background, which environment are you using hvplot with? I'm guessing the problem is that it's not a IPython or notebook environment, in which case there is no ``_loaded`` attribute defined.

Resolving patch:
diff --git a/hvplot/__init__.py b/hvplot/__init__.py
--- a/hvplot/__init__.py
+++ b/hvplot/__init__.py
@@ -68,7 +68,7 @@ def patch(library, name='hvplot', extension=None, logo=False):
             raise ImportError('Could not patch plotting API onto intake. '
                               'intake could not be imported.')
         setattr(intake.source.base.DataSource, name, patch_property)
-    if extension and not _hv.extension._loaded:
+    if extension and not getattr(_hv.extension, '_loaded', False):
         _hv.extension(extension, logo=logo)
 
 
diff --git a/hvplot/intake.py b/hvplot/intake.py
--- a/hvplot/intake.py
+++ b/hvplot/intake.py
@@ -11,5 +11,5 @@
         patch('intake', extension='bokeh')
         patch('intake', 'plot')
     else:
-        if not _hv.extension._loaded:
+        if not getattr(_hv.extension, '_loaded', False):
             _hv.extension('bokeh', logo=False)


Test patch:
Repository: holoviz/hvplot

Issue:
hvplot(cmap=[]) doesn't accept lists but hvplot().opts(cmap) does
Doesn't work
```
import xarray as xr
import hvplot.xarray

da = xr.tutorial.open_dataset('air_temperature').isel(time=0)['air']
da.hvplot('lon', 'lat', cmap=['red', 'blue', 'green'])
```

Works
```
import xarray as xr
import hvplot.xarray

da = xr.tutorial.open_dataset('air_temperature').isel(time=0)['air']
da.hvplot('lon', 'lat').opts(cmap=['red', 'blue', 'green'])
```


Discussion:
Do you know if this used to work? I have been messing around with the cmap kwarg a bit. 

Resolving patch:
diff --git a/hvplot/converter.py b/hvplot/converter.py
--- a/hvplot/converter.py
+++ b/hvplot/converter.py
@@ -723,7 +723,7 @@ def _process_style(self, kwds):
                     else:
                         cmap = cmap or self._default_cmaps['linear']
 
-        if cmap in self._default_cmaps:
+        if isinstance(cmap, str) and cmap in self._default_cmaps:
             cmap = self._default_cmaps[cmap]
 
         if cmap is not None:


Test patch:
diff --git a/hvplot/tests/testoptions.py b/hvplot/tests/testoptions.py
--- a/hvplot/tests/testoptions.py
+++ b/hvplot/tests/testoptions.py
@@ -218,12 +218,17 @@ def test_cmap_opts_by_type(self):
         opts = Store.lookup_options('bokeh', plot, 'style')
         self.assertEqual(opts.kwargs['cmap'], 'coolwarm')
 
-    def test_cmap_opts_in_call(self):
+    def test_cmap_opts_by_name(self):
         plot = self.df.hvplot.scatter('x', 'y', c='number', cmap='fire')
         opts = Store.lookup_options('bokeh', plot, 'style')
         self.assertEqual(opts.kwargs['cmap'], 'fire')
 
-    def test_colormap_opts_in_call(self):
+    def test_colormap_opts_by_name(self):
         plot = self.df.hvplot.scatter('x', 'y', c='number', colormap='fire')
         opts = Store.lookup_options('bokeh', plot, 'style')
         self.assertEqual(opts.kwargs['cmap'], 'fire')
+
+    def test_cmap_opts_as_a_list(self):
+        plot = self.df.hvplot.scatter('x', 'y', c='number', cmap=['red', 'blue', 'green'])
+        opts = Store.lookup_options('bokeh', plot, 'style')
+        self.assertEqual(opts.kwargs['cmap'], ['red', 'blue', 'green'])
Repository: holoviz/hvplot

Issue:
Loading color_key while using hvplot.Scatter with datashader=True
Hi,

Is there anyway to load a custom color_key to datashader used while calling hvplot.Scatter with datashader=True?
I need to include a legend for the scatter points colors.  I'm using the recommended workaround and know how to do this while calling datashade(....color_key=colorDict).   I'm looking for a way to do it while using hvplot.
Thanks.


Discussion:
I'm not sure what the question is, exactly.  Once you provide the color_key as above, you can overlay the corresponding color_points object from http://holoviews.org/user_guide/Large_Data.html the same for hvPlot as for HoloViews; hvPlot returns a HoloViews object that will work the same as if you created it with HoloViews.

Resolving patch:
diff --git a/hvplot/converter.py b/hvplot/converter.py
--- a/hvplot/converter.py
+++ b/hvplot/converter.py
@@ -740,7 +740,10 @@ def _process_style(self, kwds):
         if cmap is not None:
             style_opts['cmap'] = cmap
 
-        color = style_opts.get('color', process_cmap(cmap or self._default_cmaps['categorical'], categorical=True))
+        if not isinstance(cmap, dict):
+            color = style_opts.get('color', process_cmap(cmap or self._default_cmaps['categorical'], categorical=True))
+        else:
+            color = style_opts.get('color')
         for k, v in style.items():
             if isinstance(v, Cycle):
                 style_opts[k] = Cycle(values=color) if isinstance(color, list) else color


Test patch:
diff --git a/hvplot/tests/testoperations.py b/hvplot/tests/testoperations.py
--- a/hvplot/tests/testoperations.py
+++ b/hvplot/tests/testoperations.py
@@ -75,6 +75,10 @@ def test_aspect_and_frame_height_with_datashade_and_dynamic_is_false(self, opt):
         self.assertEqual(opts.get('height'), None)
         self.assertEqual(opts.get('frame_width'), None)
 
+    def test_cmap_can_be_color_key(self):
+        color_key = {'A': '#ff0000', 'B': '#00ff00', 'C': '#0000ff'}
+        self.df.hvplot.points(x='x', y='y', by='category', cmap=color_key, datashade=True)
+
 
 class TestChart2D(ComparisonTestCase):
Repository: holoviz/hvplot

Issue:
default cmap for categorical should change depending on # of categories 
The default cmap for categorical is Category10 so when more than 10 categories are in a dataset colors are recycled. It would be nice if the cmap would change to 'Category20' for example, when 15 categories are shown.


Discussion:
I'd just change the default to glasbey_category10 (see https://colorcet.pyviz.org/user_guide/Categorical.html) to give 256 available colors without affecting the first 10.
Should we do this in hvplot 0.5.0? We are setting a new default cmap for linear data, so might make sense. 

Resolving patch:
diff --git a/hvplot/converter.py b/hvplot/converter.py
--- a/hvplot/converter.py
+++ b/hvplot/converter.py
@@ -7,6 +7,7 @@
 import holoviews as hv
 import pandas as pd
 import numpy as np
+import colorcet as cc
 
 from bokeh.models import HoverTool
 from holoviews.core.dimension import Dimension
@@ -270,7 +271,7 @@ class HoloViewsConverter(object):
 
     _default_cmaps = {
         'linear': 'kbc_r',
-        'categorical': 'Category10',
+        'categorical': cc.palette['glasbey_category10'],
         'cyclic': 'colorwheel',
         'diverging': 'coolwarm'
     }


Test patch:
diff --git a/hvplot/tests/testoptions.py b/hvplot/tests/testoptions.py
--- a/hvplot/tests/testoptions.py
+++ b/hvplot/tests/testoptions.py
@@ -206,9 +206,10 @@ def test_holoviews_defined_default_opts_logx_overwritten_in_call(self):
         self.assertEqual(opts.kwargs.get('logz'), None)
 
     def test_hvplot_default_cat_cmap_opts(self):
+        import colorcet as cc
         plot = self.df.hvplot.scatter('x', 'y', c='category')
         opts = Store.lookup_options('bokeh', plot, 'style')
-        self.assertEqual(opts.kwargs['cmap'], 'Category10')
+        self.assertEqual(opts.kwargs['cmap'], cc.palette['glasbey_category10'])
 
     def test_hvplot_default_num_cmap_opts(self):
         plot = self.df.hvplot.scatter('x', 'y', c='number')
Repository: holoviz/hvplot

Issue:
Using by on datashade/rasterize plot
As described in this [SO post](https://stackoverflow.com/questions/58378802/aggregation-column-category-not-found-when-i-set-datashader-true-with-hvplot), the datashade/rasterize operations try to apply to the `by` column even though that column is being grouped over and therefore no longer exists.


Discussion:

Resolving patch:
diff --git a/hvplot/converter.py b/hvplot/converter.py
--- a/hvplot/converter.py
+++ b/hvplot/converter.py
@@ -968,7 +968,7 @@ def __call__(self, kind, x, y):
             else:
                 opts['cmap'] = process_cmap(cmap, levels)
 
-        if self.by:
+        if self.by and not self.subplots:
             opts['aggregator'] = reductions.count_cat(self.by[0])
         if self.aggregator:
             agg = self.aggregator


Test patch: