[no-ci] Claim context7 repo#1757
Conversation
|
Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
mdboom
left a comment
There was a problem hiding this comment.
Can we add a comment (I guess as a key/value pair since JSON doesn't support comments) that links to the description of what this does? I think our future selves may forget why this is here.
Is there anyway this can be a hidden file or not at the top-level? No worry if not.
|
I look at their docs but unfortunately i dont think we can add a comment and the file needs to be in the root of the repo. |
|
Let's make a decision here. JSON famously doesn't support comments. We have |
|
I'm fine with relying on {
"$schema: "https://context7.com/schema/context7.json",
"description": "NVIDIA cuda-python ownership claim for Context7 MCP documentation",
"url": "https://context7.com/nvidia/cuda-python",
"public_key": "pk_gupaHhsdvsuT1j3BZpb7i"
} |
|
I would just rely on the commit message, that description field its for describing what the project does for coding agents. |
That seems useful; what I suggested in my previous comment would seem to fit that expectation, and it's a trivial effort to make the change? |
|
Yeah I am not opposed to adding a description, just that I would not add a line mentioning ownership, Context 7 or MCP. Instead it would be like: CUDA Python documentation, libraries include cuda.bindings, cuda.core. or something like that that describes what we provide there. |
Context7 (https://context7.com) is an MCP server that indexes library documentation and serves it to AI coding assistants. This file registers NVIDIA as the owner of the cuda-python project on Context7, giving us control over how and when our documentation is parsed and indexed. See https://context7.com/nvidia/cuda-python for the resulting page and https://context7.com/docs/adding-libraries for the file format reference. Made-with: Cursor
|
@danielfrg I added a description. Good? @mdboom Could you please look again, to unblock merging this PR? |
|
Do we need to run CI on this one too even with the |
|
/ok to test 73db51f |
Yes, but it will be very quick: all builds and tests are skipped with the The bot doesn't seem to trigger, probably because it thinks the CI ran already (I cancelled it manually yesterday, to not waste resources). I'll update the branch again, that should do the trick hopefully. |
|
Roborev jobs NVIDIA#1756 and NVIDIA#1757 surfaced four medium findings: * (NVIDIA#1756 medium @ _program_cache.py:1390) ``FileStreamProgramCache.__contains__`` routed through ``__getitem__``, which read the full payload and called ``_touch_atime``. Membership probes thus counted as LRU reads, inverting eviction relative to genuine reads. Fixed by making ``__contains__`` a stat-only ``self._path_for_key(key).exists()`` check. * (NVIDIA#1756 medium @ _program_cache.py:440) NVRTC uses ``options.name`` as the source filename and resolves quoted ``#include "x.h"`` directives relative to its directory. The cache cannot observe edits to neighbour headers, so an ``options.name`` with a directory component must require an ``extra_digest`` -- the same treatment ``include_path``/``pre_include`` already get. Added the guard in ``make_program_cache_key`` (rejecting ``"/"`` and ``"\\"`` in ``options.name`` on the NVRTC backend when ``extra_digest`` is ``None``). * (NVIDIA#1757 medium @ _program.pyx:156) Cache hits dropped ``ObjectCode.symbol_mapping`` even when ``name_expressions`` were provided. The first call (miss) returned an ObjectCode WITH mappings; every subsequent call (hit) returned one WITHOUT -- silently breaking later ``get_kernel(name_expression)`` lookups that worked on the uncached path. Fixed by rejecting non-empty ``name_expressions`` in ``Program.compile(cache=...)`` so hit and miss behavior cannot diverge. Compiles that need ``name_expressions`` should run without ``cache=``, or look up mangled symbols by hand from the cached ``ObjectCode``. * (NVIDIA#1757 medium @ _program.pyx:142) The ``Program.compile`` docstring claimed NVRTC ``options.name`` with a directory component is rejected, but the wrapper just delegated to ``make_program_cache_key`` without that helper enforcing it. Now enforced (via the helper, per the previous bullet) and tested end-to-end via the wrapper. Tests cover the new rejections (parametrized over ``/``, ``\\``, absolute paths, parent-relative paths), the ``extra_digest`` escape hatch, the ``name_expressions`` rejection (and that an empty ``name_expressions`` is still accepted), and the ``__contains__`` atime-preservation invariant (hammer membership on a cold key, then write a third entry; the cold key must evict, proving the membership probes did not promote it).
This is just to claim that we own the cuda-python repo on context7.
Context7 is a popular MCP server for getting code doc into agents and we should keep it updated, right now the last automatic built they did was 6 months ago. With this we can control it more.