Skip to content

feat: add docker path mappings for remote and monorepo workflows - #109

Draft
William-Blackie wants to merge 8 commits into
nvim-neotest:masterfrom
William-Blackie:williamblackie/docker-path-mappings
Draft

feat: add docker path mappings for remote and monorepo workflows#109
William-Blackie wants to merge 8 commits into
nvim-neotest:masterfrom
William-Blackie:williamblackie/docker-path-mappings

Conversation

@William-Blackie

@William-Blackie William-Blackie commented Mar 29, 2026

Copy link
Copy Markdown

Summary

Add host/container path mapping support for remote Python commands, including Docker-oriented DAP attach hooks, translated result paths, and docs/examples for general and monorepo setups.

Problem

neotest-python currently assumes Neovim and the Python test process share the same filesystem. That breaks for Docker and other remote execution flows where test ids, helper scripts, temp files, and debug paths need to move cleanly between host and container paths.

Solution

This change adds path_mappings, cwd, env, and function-based dap hooks so the adapter can run against remote Python entrypoints while still reporting results back to host paths.

It also:

  • translates temp files, script paths, test ids, and output paths in both directions
  • derives debugpy pathMappings for attach flows
  • supports dynamic configuration for broader monorepo use cases
  • documents Docker and monorepo examples
  • adds Lua coverage for path translation and adapter spec generation

This is still a work in progress, but feedback is welcome. The intent is to keep this generally useful for both standard repositories and monorepos rather than tailoring it to one Docker layout.

Reviewer notes

The main areas worth pressure-testing are:

  • path translation edge cases for temp files and nested mappings
  • whether the dap callback/context shape is the right long-term API
  • whether the monorepo/root override examples match real-world adapter usage

Update (2026-07-23)

Added a README note + example based on real-world usage of this branch in a
docker-compose monorepo: python/path_mappings/env are called on every
discover_positions (most buffer parses of a test file), not just on run, so
anything non-trivial (e.g. reading a docker-compose.yml to derive a service
name instead of hardcoding one per directory) should be memoized per root.
This also confirms the function-based python/path_mappings API holds up
for a real monorepo, not just the illustrative example.

python/path_mappings/env run on every discover_positions call (most
buffer parses of a test file), not just on run, so recomputing
anything non-trivial per call is wasteful. Add a real-world-informed
example deriving the docker-compose service from the compose file
instead of a hand-maintained lookup table, memoized per root.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant