flake8 isn't linting with an empty machine

[nickjj]

Hi,

I installed the extension and then added this as my workspace settings:

{
        "docker-linter.flake8.machine": "",
	"docker-linter.flake8.enable": true,
	"docker-linter.flake8.container": "foobar_web_1"
}

I'm running Docker for Windows, so Docker Toolbox is not in play and foobar_web_1 is an example application that has flake8 installed (and it works if I manually docker exec into the container and run it).

I even took your playground-python example and ran it (with the "" machine) but it fails with the same problem as my project. There's no visual feedback inside VSCode that the linter is operational.

If the container is stopped, then I do get an error inside of VSCode asking if the container is running.

Any ideas?

[henriiik]

Hello!

Your settings look good.

The only visual feedback you should get is when there is a problem, so if you fire upp the playground, and remove the: after "__main__", you should get the following.

But I am assuming that since you are opening this issue, your problems tab is empty even when there are problems?

If you run flake8 on the file, when there is a problem like above, what do you get?

ex:

$ docker-compose run web flake8 web.py                                                                                            
web.py:10:25: E999 SyntaxError: invalid syntax
web.py:11:5: E113 unexpected indentation

[nickjj]

My problem tab is empty after mangling the source code, and when I docker exec into the container and execute flake8 then I see the problems come up, but only in the output of flake8 from the command line, not VSCode.

Here's what it looks like in my editor:

Terminal output if I run it manually

The problems panel showing no issues

It's worth mentioning I'm running gunicorn so the container didn't die from the syntax error, but this same behavior happens with your test app too.

[nickjj]

Also it's worth mentioning I have the same issue with Rubocop too, so I don't think it's isolated to flake8.

[henriiik]

I see. It sounds a lot like the linting command is being run but it's not getting any output, so it might be a problem with sending things to the container via stdin. The implementation passes the current buffer contents to the command via stdin so it can work with unsaved changes. The actual command run would be more like the following.

cat snakeeyes/app.py | docker exec -i snakeyes_website_1 flake8 -

[henriiik]

I’ll try and get out a version of the extension with a debug setting today

[nickjj]

That command produces the correct flake8 output when I run it in the terminal:

I added a couple of extra line breaks.

nick@workstation:/e/08-testing-and-code-quality$ cat snakeeyes/app.py | docker exec -i snakeeyes_website_1 flake8 -
stdin:8:1: E303 too many blank lines (4)

Thanks. It's also worth mentioning I have VSCode configured to use the WSL bash terminal too. I'm not sure if that would matter but more information is better than less.

My environment is:

• VSCode Insiders (1.19.0 from Nov 17th)
• "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe"
• "terminal.external.windowsExec": "C:\\WINDOWS\\System32\\bash.exe"
• Windows 10 Professional
• Docker for Windows CE v17.10.0

[henriiik]

Good to know!

Some questions: Are you running your docker commands in WSL? Do you have a docker executable in WSL or are you using the one that came with docker for windows? If you have a docker binary in WSL is it available on the path outside of WSL?

[nickjj]

1. Yes they are being ran through WSL.
2. I installed the native Ubuntu version of Docker within WSL (which is only acting as the Docker CLI). Full details on how I have it set up can be found at https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly.
3. In this case it would use the binary provided by Docker for Windows instead of the Docker CLI from WSL. The Docker for Windows binary is available where as the one from within WSL is not.

[henriiik]

Thanks for your answers. I have released a new version of the extension with a debug setting, if you set docker-linter.debug to true you should get an output tab that shows exactly what command is being run and what the output is.

[nickjj]

I updated the extension but the output window is empty.

[henriiik]

there is a little dropdown to the right, where it says tasks. There should be a Docker Linter option.

[nickjj]

Ah, I missed that. Here's the output after changing the app.py file:

flake8: Validation finished for: file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py
flake8: Validation requested for: file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py
flake8: Running command: 'docker exec -i snakeeyes_website_1 flake8 -'
flake8: Validation requested for: file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py
flake8: Command exited with code: 0

flake8: Re-validating: file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py
flake8: Validation requested for: file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py
flake8: Running command: 'docker exec -i snakeeyes_website_1 flake8 -'
flake8: Command exited with code: 0

flake8: Validation finished for: file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py

[henriiik]

It does indeed look like it's executing the command correctly but is unable to pass the contents of the file into the container.

[nickjj]

Any idea what's up with the %3A as being part of the file path? Google says %3A is a ":".

The pwd of the code's directory is /e/08-testing-and-code-quality. There is no ":" present.

My e drive is set up to be a shared folder with Docker for Windows and it's also being mounted into WSL. Currently volumes are working as normal. My Compose file uses - '.:/snakeeyes' and when I make a code change I can see the new version in the running container.

[henriiik]

It is the Windows path to the file.

But VSCode should pull the contents directly from the buffer in the editor so the file path should not matter.

I don’t have access to a windows computer right now but I will look into it further tomorrow.

[nickjj]

Ok thanks and yeah it seems that the path is accurate because if I browse to file:///e%3A/08-testing-and-code-quality/snakeeyes/app.py it loads the file.

Also I just removed WSL from the equation here by launching VSCode through PowerShell and running a docker-compose up through PowerShell (which uses the Docker for Windows CLI). I get the same exact results as through WSL. The debug output is the same and there's no problems listed.

And for completeness I even moved my source code to C:\Users\Nick\08-testing-and-code-quality and it yields the same result so I don't think it's related to using an external drive in any way.

[henriiik]

Hello!

I tried both stable and edge docker for windows, and i cannot reproduce your issue unfortunately.

Here it is, running on edge.

The only thing i can think of is that it is a bug with your particular version of docker (you said above you are using Docker for Windows CE v17.10.0) i would recommend installing the latest edge (17.11.0-ce-rc4, like in the screenshot above) or the latest stable and seeing if that helps.

Other than that there is not much i can do, unless you want to try your hand at debugging the extension yourself in which case i might be able to give some guidance. :)

[nickjj]

Can you try using WSL and installing Ubuntu Docker within WSL? The set up you're using now is so much different.

[henriiik]

I had docker in WSL from before but it does not seem to affect the outcome

[nickjj]

Did you install the Ubuntu version of Docker in WSL?

What happens if you run which docker from there? If it doesn't report back /usr/bin/docker I think it's worth trying to install the Ubuntu version of Docker in WSL.

[henriiik]

yeah its the ubuntu version,

[nickjj]

Ok thanks. I will try updating Docker today and see what happens.

One other thing to test on your end would be to set this in your VS Code settings:

"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
"terminal.external.windowsExec": "C:\\WINDOWS\\System32\\bash.exe"

[henriiik]

I tried that to, it does not make a difference.

One thing i thought about is if you are running an insiders version of windows (I am not)? Perhaps that makes a difference. :)

[nickjj]

I'm running the official stable version of Windows 10 Pro with the 2017 Fall Content Creators update applied. The exact build is 1709 / 16299.64.

Are you running the 2017 Fall update too? If not, you can manually download and update it through MS (if you're willing). You can do that by updating from https://www.microsoft.com/en-us/software-download/windows10.

[henriiik]

I am running the same version as you. :)

[nickjj]

Ok. v17.11 is 97% complete going by the milestones, so I think I'll just hang until it ships. I don't know the ETA but hopefully within a couple of days.

I will let you know the day v17.11 comes out.

[nickjj]

Just upgraded to v17.11 (both Docker for Windows and the WSL Docker client) and I have the same issue as with the previous version.

Any ideas on what we could do to debug this?

[henriiik]

Running out of ideas unfortunately. One thing i thought of is perhaps you have some old version of docker lying around in your path? if you open a power shell and run (get-command docker).Path what do you get?

ex:

C:\var\data\vscode-docker-linter\playground-python [master ≡ +0 ~1 -0 !]> (get-command docker).Path
C:\Program Files\Docker Toolbox\docker.exe

Otherwise i guess last option is for you to clone the repo and run the extension in debug mode :)

[nickjj]

I get C:\Program Files\Docker\Docker\Resources\bin\docker.exe, but I am running Docker for Windows, not Docker Toolbox. I have never had Docker installed any other way.

docker info reports back Server Version: 17.11.0-ce docker --version reports back Docker version 17.11.0-ce, build 1caf76c

[nickjj]

I made some progress poking around your repo's codebase.

I didn't run it in development mode but I noticed you expose a command option.

If I set "docker-linter.flake8.command": "flake8 .", then I get the expected results in the problems tab. I know this limits me to only seeing feedback on save, but at least we're 1 step closer to victory.