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
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?
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.)
Why is NeoVim dead to you?