Thanks for the feedback! I’ll update the README to clarify these points.
You can view the full Pytest output using the :PytestOutput command. This shows all outputs from failing tests (since Pytest doesn’t display output for passing tests by default).
I also plan to implement support for custom arguments — for example, Pytest's -s flag to show stdout even when tests pass.
If Docker is disabled, all Docker-related features are also disabled.
When Docker Compose is enabled, its configuration takes precedence over the plugin’s direct settings.
The prefix_app setting maps your local directory to the Docker path.
For example, if your current working directory is ~/projects/, and the prefix is app, the Docker path /usr/src/app will map to ~/projects/app.
Docker is responsible only for path mapping and executing the Pytest command inside a running container — the container must already be running.
If you're using Docker Compose, the plugin retrieves the Docker path from the volume configuration.
For example, if your docker-compose.yml contains:
volumes:
- app:/usr/src/app
Then /usr/src/app will be used as the Docker path.
If enable_docker_compose is set to false, the plugin will fall back to the manually configured path instead. (Note: the container itself is not retrieved from Docker Compose at this point.)
Very cool integration of neovim with pytest! I also am using neovim with python integration for my hobby project, vimgolf.ai , where I try to teach vim motions to those who haven't used vim. Only two levels so far, but hoping to increase that count in the near future.
I get the problem with spending too much time configuring things like Vim or Tmux. But I'm just getting started with NeoVim today to see if I want to go with it full time and get off of Vim.
I switched from Vim to NeoVim about a year ago and have been quite pleased. Other than having to `alias vim='nvim'` due to unconquerable muscle memory, I haven't really noticed any change other than having a lot more plugin options
What happens if your test produces a bunch of stdout, such as using `print(...)` somewhere? Where would it be displayed?
A couple of questions about Docker based on the README:
> enabled = true, -- Enable docker support
What does this do in the end? Is it starting containers or adjusting which test command gets run by prefixing a Docker command?
If so is there a way to opt out of that to have it still use Docker commands without it managing container lifecycles?
> docker_path = '/usr/src/app', -- This is the default path, if you use docker compose this is obtained from the docker compose file
How is this being read from that file? Are you reading a volume?
Is this meant to be what the WORKDIR is set to?
> docker_path_prefix = 'app', -- This is the prefix for the path in the cwd in your local, for example: root/app/<docker_app_content>
Is this meant to be what the WORKDIR is set to or what the COMPOSE_PROJECT would be set to?
> container = 'app-1', -- Container where the tests will be run
Will this be ignored in favor of the compose service name if compose is set to true?
> docker_compose_file = 'docker-compose.yml', -- This is the default docker compose file name
The default name has been compose.yaml for a long time now btw, you may want to support both out of the box.
> enable_docker_compose = true, -- Enable docker compose support
What does this do vs not having it enabled?
Thanks for the feedback! I’ll update the README to clarify these points.
You can view the full Pytest output using the :PytestOutput command. This shows all outputs from failing tests (since Pytest doesn’t display output for passing tests by default). I also plan to implement support for custom arguments — for example, Pytest's -s flag to show stdout even when tests pass.
If Docker is disabled, all Docker-related features are also disabled. When Docker Compose is enabled, its configuration takes precedence over the plugin’s direct settings.
The prefix_app setting maps your local directory to the Docker path. For example, if your current working directory is ~/projects/, and the prefix is app, the Docker path /usr/src/app will map to ~/projects/app.
Docker is responsible only for path mapping and executing the Pytest command inside a running container — the container must already be running.
If you're using Docker Compose, the plugin retrieves the Docker path from the volume configuration. For example, if your docker-compose.yml contains:
volumes: - app:/usr/src/app
Then /usr/src/app will be used as the Docker path. If enable_docker_compose is set to false, the plugin will fall back to the manually configured path instead. (Note: the container itself is not retrieved from Docker Compose at this point.)
For the longest time I've been using vims built-in `compiler` feature with tartansandal/vim-compiler-pytest combined tpope/vim-dispatch
Could you share an example of a workflow using the built in feature to run tests in Vim?
Sure, here's a recorded example: https://www.youtube.com/watch?v=TUeousvp4PQ
Interesting approach! Can you share more about this?
Rather than write something up or linking to a bunch of articles I recorded a quick screen capture: https://www.youtube.com/watch?v=TUeousvp4PQ
Very cool integration of neovim with pytest! I also am using neovim with python integration for my hobby project, vimgolf.ai , where I try to teach vim motions to those who haven't used vim. Only two levels so far, but hoping to increase that count in the near future.
Thanks! Really cool idea! I'm happy to help if you need — just share the link whenever you're ready!
Nice. Might be good to add to the README what you intend to improve on: https://github.com/nvim-neotest/neotest?tab=readme-ov-file
Yeah! I will. Thanks!
neovim is dead to me and yet I still spend ~hours a week configuring my editor to behave the way I want. whats wrong with me send help
I get the problem with spending too much time configuring things like Vim or Tmux. But I'm just getting started with NeoVim today to see if I want to go with it full time and get off of Vim.
Why is NeoVim dead to you?
I switched from Vim to NeoVim about a year ago and have been quite pleased. Other than having to `alias vim='nvim'` due to unconquerable muscle memory, I haven't really noticed any change other than having a lot more plugin options
wasted too many hours of my life trying to configure basic things, then after all that time it still just segfaults lmao
[dead]
It's a Neovim issue haha, but is fun and powerful do it!
Very nice! Congrats on your release!
Thanks!!
This is so helpful, congrats!
Thanks!