[sridipbasu]

Summary

While looking at the kaggle kernels pull flow, I found that pulling a kernel into a folder that already holds a different kernel's kernel-metadata.json overwrites that kernel's local code file.

For example, with a folder containing kernel-metadata.json for owner/kernel-a (code_file: kernel-a.ipynb), running:

kaggle kernels pull owner/kernel-b -p <folder>

writes the source of kernel-b into kernel-a.ipynb. Any local edits to kernel-a.ipynb are lost, no kernel-b file is created, and the command exits with code 0.

The issue was that kernels_pull() reuses the code_file from any kernel-metadata.json it finds in the target folder, without checking that the metadata id belongs to the kernel being pulled. This reuse was meant for pulling the same kernel again.

Fix

I changed the metadata fallback to reuse code_file only when the metadata id matches the requested owner and slug. The comparison is case-insensitive and ignores the version.

When the IDs do not match, the existing default file name (<slug>.<ext>) is used.

Pulling the same kernel again still reuses its code_file as before. The kernel=None path that reads the kernel ID from the local metadata is unchanged. No changes were made to the API request or the Python library method signature.

Tests

Added test_kernels_pull_code_file_only_reused_for_same_kernel using a real temporary folder. It covers:

• Pulling a different kernel: the source goes to <slug>.py and the existing local file is left untouched.
• Pulling the same kernel with different casing in the metadata id: the existing code_file is reused.

The test fails with the old implementation and passes with this fix.

Ran:

pytest tests/unit/test_kernels_pull.py
pytest tests/unit

Results:

11 passed, 2 subtests passed
1454 passed, 1 warning, 50 subtests passed

The warning is an existing unrelated DeprecationWarning.

Also ran the Black check, which passed.

I also verified the behavior against the live API. Pulling one of my kernels into a folder holding another kernel's metadata now creates a new file and leaves the existing one unchanged. Pulling the same kernel still writes to the code_file from the metadata.

This change only affects the local file name chosen during kernels pull. It does not change the API requests, the Python library API, or any waiting and polling flow.

[stevemessick]

Nice, thanks!