How well does pydocenv handle those kind of issues?
> VSCode has no idea about your env because it's effectively non-local.
This is an issue that I'm aware of, and I actually didn't think about a possible solution yet. Currently, it is in a VERY early stage, but I wanted to share it to get feedback from the community and how much interest the project could raise.
The only things that I thought were adding support for example for aliasing of some commands such as running `flake8` will actually call `flake8` inside the container. But it's still very fuzzy in my head.
It has support to use a a particular interpreter, specific virtual env, or it lets you say “my interpreter is inside this docker container”, which is even allowed to be on a remote host (although I’ve always used docker running locally).
They did a good job but it doesn't seem complete yet.
If you need to isolate a part of the file system, e.g. if your environment only concerns Python files, the standard virtualenv (or venv) is perfectly powerful; if you need to isolate other parts of the system, such as memory, installed binaries and the such, your best bet is vagrant (combined with something like VirtualBox). And both of them work fine with a local IDE.
Docker works best for deployment, when you want to set up a running process in a consistent manner, and its closed-box approach works really well in that scenario. But in development you generally want more flexibility.